ソース管理からの DB オブジェクトの移行の自動化

Question

ソース管理からのストアド プロシージャ/ビュー/関数/テーブルの変更の展開を自動化するための「ベスト プラクティス」を探しています。私は StarTeam と ANT を使用しているので、ラベル付けは処理されます。私が探しているのは、必ずしも StarTeam ではなく、ソースからのこれらのオブジェクトのプルの自動化にどのように取り組んでいる人がいるかということです。

最終的には、実行、チェックイン、ラベル付けできる 1 つのスクリプトを作成したいと考えています。

私は誰かにそれを書くことを求めているわけではありません。過去にうまくいった（またはうまくいかなかった）いくつかのアイデアやアプローチだけです。

私は混乱を片づけようとしており、これをできる限り「正しい」状態に近づけたいと考えています。

テーブル/ビュー/関数などを保存しています。StarTeam の個々のファイルにあり、DB は SQL 2K5 です。

Answer 1

redgate の SQL Compare を使用します (http://www.red-gate.com/).

弊社には運用データベースと開発データベースがあり、各開発者は独自のデータベースを持っています。

開発データベースは、開発者が変更をチェックインするときにデータベースに加えた変更と同期されます。

開発者は、同期スクリプトと SQL Compare によって生成された比較レポートもチェックインします。

アプリケーションをデプロイするときは、SQL Compare を使用して開発データベースを運用データベースと同期するだけです。

私たちのアプリケーションは社内でのみ使用するため、これはうまく機能します。これがあなたのシナリオではない場合は、SQL Packager (これも redgate から) を検討します。

Answer 2

チェックイン 移行 (からの指摘 アンドリュー・ピーターズ で 別の投稿)

Answer 3

私はビュー、プロシージャ、トリガー (自由に再作成できるオブジェクト) をテーブルから分離することを好みます。ビュー、プロシージャ、トリガーについては、それらをチェックアウトして最新のものを再作成するジョブを作成するだけです。

テーブルの場合は、1 行のデータベース バージョン テーブルを使用することを好みます。この表を使用して、どの新しい更新が適用されていないかを判断します。その後、各更新が適用され、バージョン番号が更新されます。更新が失敗した場合は、その更新のみを確認する必要があり、以前の更新が再度行われないことを確認して再実行できます。

Answer 4

Carl が指摘したように、diff ユーティリティを使用して更新スクリプトを作成できます。RedGate は優れた製品を製造していますが、SQL Server 2k5 には以下の機能が付属しています。 テーブル差分 これも同様に機能するはずです。