Webアプリケーションで、データベース構造を最新の状態に保つにはどうすればよいですか？

Question

アプリケーションのデプロイ後にデータが変更された場合、データベースをどのように最新の状態に保ちますか？

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

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

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

しかし、何かを変更するたびに完全なアップグレードスクリプトを書くのは苦痛で、エラーが発生しやすいようです。少なくともこのようなアトミックな変更。

また、異なる顧客がいつでも異なるデータベースバージョンを実行していることを期待できるので、どの時点からでも上に行く方法が本当に必要です。

Answer 1

個人的には、あなたがリストしたものと非常によく似たプロセスを使用します。変更についてのあなたの議論を見ることができますが、私はめったに変更を加えません。テストでは、はい、それは起こりますが、実際の本番サイトに関しては、私はそれを大したことではないと思います。

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

Answer 2

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

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

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

最後に、データベース設計はアプリケーション設計の基盤を形成します。適切なソフトウェアエンジニアリングにより、展開前に比較的安定したデータベーススキーマが得られるはずです。データベーススキーマへのその後の変更は、小さくて頻繁ではありません。

Answer 3

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

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

Answer 4

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

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

Answer 5

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

サイトを更新すると、新しいスクリプトが検出されて実行されます。これは、データの1回限りの変更を行うことができるため、SQL Compareなどのツール（非常に気に入っています）よりも優れています。ただし、更新後に SQL CompareおよびSQL Data Compareを（選択したテーブルで）実行して、プロシージャが正しく機能することを確認します。正常に実行されると、操作全体がコミットされ、データベースは「スクリプトの実行」を更新します。これらのスクリプトが再度実行されないように情報を提供します。

この方法で行うことの良い点は、「忘れる」ことができないことです。スクリプト。さらに、テスト用データベースまたはステージングデータベースにロールしようとすると、多くの場合、代替データセットが本番環境に到達する前にフェレットアウトするという隠れた仮定を見つけます。

これのもう1つの利点は、さまざまなお客様に対してさまざまな機能レベルでさまざまなインストールを維持できることです。ただし、アップグレードを行うと、すべてのスクリプトが適切に実行されます。このスキームで私が抱えていた唯一の問題は、「順不同」です。ユーザーのデータベースに適用されるパッチ...元の状態が予想どおりであることを検出し、そうでない場合は中止するためにスクリプトを記述する必要があります。

Answer 6

AtwoodがDBのバージョン管理で書いたホラーのコーディングに関する記事をしばらく読んでください：データベースはバージョン管理下にありますか

Answer 7

RedGateのSQLCompareまたはxSQL SoftwareのxSQLオブジェクトなどのツールを使用して、オンザフライでdiff / delta T-SQLスクリプトを生成します。

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

異なるデータベースを持つ異なる顧客の場合、単に比較するための異なる参照データベースがあります。更新プログラムを顧客にリリースしたら、同じdiffスクリプトを使用して独自の参照サイトを更新します。

これで簡単です。

Answer 8

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

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

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