現在、データベース スクリプト (テーブル、プロシージャ、関数、ビュー、データ修正) を Subversion に保存する方法を検討していますが、最善のアプローチについて何らかの合意があるかどうか知りたいです。
考慮する必要がある要素には次のようなものがあります。
- 「作成」スクリプトをチェックインするか、「変更」スクリプトで増分変更をチェックインするか
- 特定のリリースのデータベースの状態をどのように追跡するか
- 任意のリリースバージョンに対してデータベースをゼロから構築するのは簡単であるべきである
- データベース内に、そのデータベースに対して実行されたスクリプトやデータベースのバージョンなどをリストするテーブルが存在するかどうか。
明らかにこれはかなりオープンエンドな質問なので、人々の経験から何を学んだのかをぜひ聞きたいです。
ベストアンサー1
数回の反復を経て、私たちが採用したアプローチは、おおよそ次のようになりました。
テーブルごと、ストアド プロシージャごとに 1 つのファイル。また、データベース ユーザーの設定、ルックアップ テーブルへのデータの入力など、その他の項目についても個別のファイルを作成します。
テーブルのファイルは CREATE コマンドで始まり、スキーマの進化に合わせて一連の ALTER コマンドが追加されます。これらの各コマンドは、テーブルまたは列がすでに存在するかどうかのテストで囲まれています。つまり、各スクリプトは最新のデータベースで実行でき、何も変更されません。また、古いデータベースの場合は、スクリプトによって最新のスキーマに更新されます。空のデータベースの場合は、CREATE スクリプトによってテーブルが作成され、ALTER スクリプトはすべてスキップされます。
また、スクリプトが詰まったディレクトリをスキャンし、それらを 1 つの大きなスクリプトに組み立てるプログラム (Python で記述) もあります。このプログラムは、SQL を解析して、テーブル間の依存関係 (外部キー参照に基づく) を推測し、それらを適切に順序付けます。その結果、データベースを 1 回で仕様どおりに実行する巨大な SQL スクリプトが完成します。スクリプト組み立てプログラムは、入力ファイルの MD5 ハッシュも計算し、それを使用して、リストの最後のスクリプトの特別なテーブルに書き込まれたバージョン番号を更新します。
事故がない限り、結果として、ソース コードの特定のバージョンのデータベース スクリプトは、このコードが相互運用するように設計されたスキーマを作成します。また、新しいデータベースを構築したり、既存のデータベースを更新したりするために顧客に提供する単一の (やや大きい) SQL スクリプトが存在することも意味します。(この場合、顧客ごとに 1 つずつ、データベースのインスタンスが多数存在するため、これは重要でした。)