6

アプリケーションのデプロイ後にデータが変更された場合、データベースを最新の状態に保つにはどうすればよいでしょうか?

つまり、テーブルを追加または削除できます。これは簡単な作業です。既存のテーブルを変更することも簡単です。しかし、構造を頻繁に変更する場合、それをどのように管理しますか?

以前は、データベースに現在のデータベース バージョンのテーブルを保持していました。その後、すべてのアップグレードは、新しいテーブルの作成、列の追加、またはデータの移動など、その作業を行う SQL ファイルでした。ファイルの名前はこれらのバージョンにちなんで付けられているため、アップグレード スクリプトがデータベース バージョン 10 を取得した場合、11.sql から N.sql までのすべてのファイルを取得し、それらのそれぞれにデータベース バージョン番号を同時にインクリメントして適用しました。

これは問題なく機能しているように見えますが、疑問に思っているのは、そのようなタスクに対するあなたの戦略は何ですか?
また、このシステムは、1 つの「パッチ」でテーブルを正規化し、その後何らかの理由で再度非正規化すると、完璧には見えません。その後、2回行われます。

しかし、何かを変更するたびに完全なアップグレード スクリプトを作成するのは面倒で、エラーが発生しやすいようです。少なくとも、そのような原子的な変化よりも。

また、さまざまな顧客がさまざまなデータベース バージョンをいつでも実行していると予想できるため、どの時点からでもアップグレードする方法が必要です。

4

8 に答える 8

5

個人的に私はあなたがリストしたものと非常によく似たプロセスを使用しています.変更についてのあなたの議論を見ることができます. テストでは、確かにそうなりますが、実際の運用サイトに関しては、大したことではないと思います。

個々のバージョン スクリプトを保持することで、IMHO は展開に適しているだけでなく、ソース管理にチェックインできるアイテムを提供するのにも適しています。

于 2008-10-27T18:11:22.197 に答える
2

最初に、スキーマが設定されているアプリケーションのバージョン番号を追跡するスキーマのバージョンテーブルを導入し、個々のテーブルのバージョンを追跡します。このアプリケーションバージョンと照合するために、アプリケーションにハードコーディングするスキーマバージョンがあります。アプリケーションが間違ったバージョンのDBにアクセスすることは望ましくありません。次に、前のテーブルバージョンから現在のバージョンに移行するテーブルごとの一連のスクリプトがあります。次に、アプリケーションに埋め込んだターゲットテーブルを作成して、新しいバージョンで予想される各テーブルのバージョンを確認し、すべてに一致するかどうかを確認します。そうでない場合は、さまざまな移行スクリプトをスキーマに適用して、データベースを適切な状態にします。

複雑?幾分。救命。絶対に。スキーマが間違っているため、アプリでエラーを追跡するようなものはありません。

于 2008-10-27T18:32:03.620 に答える
2

多くのフレームワークは、「移行」の概念を使用しています。これは、データベース スキーマをあるリビジョンから次の上位リビジョンにアップグレードするスクリプトです。同様に、変更を元に戻す必要がある場合に備えて、ダウングレード スクリプトもあると便利です。これらのスクリプトは SQL の場合もあれば、抽象化されている場合もあります (Ruby on Rails など)。これらのスクリプトを手動で設計することも、他の人が言及した SQL Compare などのツールを使用することもできます。

スキーマのリビジョンを示すために、データベースに 1 列 1 行のテーブルを作成することも役に立ちます。移行をサポートする一部のフレームワークは、これに依存して、スキーマのアップグレードまたはダウングレードに適用する移行スクリプトを認識します。

アプリケーションには、アプリケーションの機能を検証するために実行できる一連のテストが必要です。このスイートに機能テストを追加して、スキーマを検査し、予想されるテーブル、列、プロシージャなどが存在することを確認することもできます。プロジェクトを修正するときは、テストを修正します。アプリケーション機能のテストは、テストするコードと共にソース管理で追跡する必要があるのと同様に、スキーマ構造のテストも追跡する必要があります。

最後に、データベース設計はアプリケーション設計の基礎を形成します。適切なソフトウェア エンジニアリングにより、デプロイ前に比較的安定したデータベース スキーマが得られるはずです。データベース スキーマに対するその後の変更は、小規模で頻繁に行う必要はありません。

于 2008-10-27T18:20:47.700 に答える
1

しばらく前に、AtwoodがコーディングホラーのDBバージョン管理について書いたアティクルを読む必要があります。データベースはバージョン管理下にありますか?

于 2008-10-27T18:34:23.617 に答える
1

Powerdesigner というツールを調べる必要があります。15 日間の完全に機能する試用版をダウンロードできます。モデル化、最新の変更の維持などに役立ちます。

これは、あなたが求めていることを実行するための優れたツールであり、さらに多くのことを行うための優れたツールです。

于 2008-10-27T18:12:00.247 に答える
1

バージョン管理リポジトリ内にリリースごとにディレクトリを作成します。そのフォルダー内のスクリプトを読み取り、ファイル名順に実行するスクリプトを作成しました (したがって、32.0.0_AddColumnXxxxYyyy などの名前でスクリプトを作成します)。このドット形式により、必要に応じてスクリプトをシーケンスに挿入できます。

サイトを更新すると、新しいスクリプトが検出されて実行されます。これは、データを 1 回で変更できるため、SQL Compare のようなツール (私が大好きです) よりも優れています。ただし、手順が適切に機能することを確認するために、更新に SQL Compare および SQL Data Compare (選択したテーブルに対して)を実行します。実行が成功すると、操作全体がコミットされ、データベースは「実行スクリプト」情報を更新するため、これらのスクリプトは再度実行されません。

この方法の良いところは、スクリプトを「忘れる」ことができないことです。さらに、テスト データベースまたはステージング データベースに移行しようとすると、本番環境に到達する前に代替データセットが探し出す隠れた仮定が見つかることがよくあります。

これのもう 1 つの利点は、さまざまな顧客向けにさまざまな機能レベルでさまざまなインストールを維持できることですが、アップグレードを行うと、すべてのスクリプトが配置され、実行する準備が整います。このスキームで私が経験した唯一の問題は、ユーザーのデータベースに適用されている「順不同」のパッチです...元の状態が期待どおりであることを検出し、そうでない場合は中止するスクリプトを作成する必要があります。

于 2008-10-27T18:15:08.693 に答える
0

RedGate の SQLCompare や xSQL Software の xSQL Object などのツールを使用して、差分/デルタ T-SQL スクリプトをその場で生成します。

必要に応じて、ビルド プロセスの一部として統合することもできます。

異なるデータベースを持つさまざまな顧客に対して、比較対象となる参照データベースが異なるだけです。更新を顧客にリリースしたら、同じ差分スクリプトを使用して自分の参照サイトを更新します。

一言でいうと以上です。

于 2008-10-27T18:10:15.537 に答える
0

私はあなたとほとんど同じ方法でそれを行います。私は、データベースのリリース ノート ファイルを保持しています。このファイルには、私の最新のものをすべて、一番上に Subversion のリビジョン番号を付けてリストしています。また、この変更を適用するために実行された SQL も含まれています。

並行して、いつでもモデルを再生成できるように、データベース モデル (Eclipse でAzzurri Clayを使用) を維持しています。必要な変更は、まずモデルに加えてから、リリース ノートを更新します。Azzurri は CREATE のみで ALTERation を生成できません。

これはすべて、必要に応じてロールバックできるように、Subversion の下に保存されます。おそらく、アプリの svn リビジョンとモデルのリビジョンの間に何らかのリンクを保持する必要があります。

于 2008-10-27T18:21:34.190 に答える