database-design - アジャイル開発とデータベース変更

Question

そこにいるアジャイル実践者のために...

プロジェクト中にデータベース スキーマへの変更をどのように管理しますか? 私の推測では、アジャイル プロジェクトでは、コードベースの場合と同様に、関連するデータベースのスキーマが変更され、リファクタリングされます。

この仮定は正しいですか？もしそうなら、物事を円滑に進めるために使用している特定のツールやプロセスはありますか?

Answer 1

AgileData.orgは、アジャイル データベース開発に関する優れたリソースです。特に、アジャイル データのベスト プラクティスに関心があるかもしれません。SQL Server を使用している場合は、Red Gateソフトウェアの SQL Compare にも興味があるかもしれません。当社の DBA は、既存のアプリケーションの QA から本番環境への変更の移行を支援してくれました。

Answer 2

更新ごとに、私は次のようになります。

• ロールフォワードおよびロールバック スクリプトの展開、
• 「DBをゼロから構築する」スクリプトを展開し、
• データ移行スクリプトのデプロイ、および
• コードがデータベースのバージョンにロックされるメカニズムを強制します。つまり、DB の現在のバージョンを返す値をテストします。不一致がある場合、システムは不一致について大声で警告します。

HTH

乾杯、

ロブ

Answer 3

アジャイルのセットアップでは、.SQL ファイルとして行われる DB 変更用のフォルダーがあります。これまでのところ、すべてのバージョンで DB を変更しており、ファイルの名前はアプリのバージョンにちなんで付けられています。インストール スクリプトは、サイトの更新時にすべての変更ファイルを自動的に適用します。

また、DB 管理ツールによって作成された、新規インストールに使用される参照 DB の完全なスキーマ ダンプもあります。

Red Gate など、このプロセスを自動化するのに役立つツールがあることは知っていますが、手動で SQL 変更ファイルを作成するのは非常に簡単です。

Answer 4

理想的には、非破壊的な変更を行い、リリースが完了したら、スキーマの古い部分を完全に非推奨にすることができます。これは簡単なことではなく、規律が必要です。常に可能であるとは限りません。

Answer 5

データベース構造はコードの多くの部分の依存関係である可能性が高く、スキーマの変更はカスケード効果をもたらします。多くのクラスが拡張するクラスのインターフェイスに変更を加えるようなものです。そのため、スキーマの変更には注意してください。

アジャイル方法論は、データベースをできる限り前もって設計することが利益になるという点で他の方法論と何ら変わりはなく、コードよりも頻繁に変更しないようにする必要があります。決して変更できないとは言いませんが、変更するにはコストがかかります。

他の人が指摘しているように、移行はスキーマの変更を追跡するためのシンプルですが効果的なツールです。概念は、スキーマのあるリビジョンから次のリビジョンにアップグレードするための CREATE および ALTER ステートメントのスクリプトであり、同じ変更をダウングレードするための ALTER および DROP ステートメントのスクリプトを伴います。Ruby on Rails は、この上にデータベース抽象化レイヤーを使用して、データベースのブランドを簡単に切り替えられるようにしますが、1 つのブランドのみをサポートする必要がある場合は、単純に SQL ファイルを使用できます。

Scott Ambler 著の「 Refactoring Databases: Evolutionary Database Design 」というタイトルの、このテーマに関する高く評価されている本があります (ただし、私はまだ購入したり読んだりしていません) 。

Answer 6

Ruby on rails migrationsを見てください。Railsを使わなくても、アイデアはすでに他のフレームワークにコピーされているので問題ありません。