SQL Server データベースを継承しました。解決しなければならないことの 1 つは、バージョン管理と自動ビルドです。
RedGate SQL Compare を推奨することについて真剣に検討する必要があると言われましたが、少し不安であることを認めざるを得ません。
私の予約は...
私の本能は、MSBuild ファイルと .SQL ファイルのスタックという試行済みのテスト済みのアプローチに固執するように指示します。
誰かがこのツールを使用した経験があるかどうか聞いてみたい.
Red Gate を使用して、デプロイ用のスクリプトを生成し、バージョン管理を制御します。
"配置" と "バージョン管理" は、SQL コードでは別の問題です。
注意すべき重要事項: 本番データベースは、すべてのデータを含むマスターです。そのため、テスト サーバーへの定期的なコピーを配置し、これをベースラインとして使用します。NUnit によって毎晩基本データが生成されるデータベース (見て、笑った) は、一般的には役に立ちません。10 億の行があり、それに対してクエリをテストする必要がある場合はどうすればよいでしょうか?
バージョニング: Red Gate ツールを使用してスキーマをベースラインとして生成し、これをこのコピー (または QA など) と比較できます。Red Gate ツールを使用すると、フォルダーと比較できます。フォルダーは、この場合、SVN の管理下にあり、リリースごとに更新されます。したがって、すべてのオブジェクトの完全な履歴があります
展開: クリーンな「ビルド」DB に対して開発スクリプト (同じく SVN) を適用し、別のクリーンな DB と比較します。これがデプロイ スクリプトになります。
もちろん、これはかなり単純化されています。
プロ版は同期と比較のための API を提供するため、必要に応じてツール チェーンに統合できます。GUI は必要ありません。ちなみに、これを使用して、クライアント コードを備えた特別なユーザー サンドボックスのワンクリック同期を提供します。
Remus が述べたように、一部の操作では絶対確実ではありません。1.5 TB のテーブルの内容を変更する場合は、私のスクリプトを愛情を込めてハンドコーディングします。もう 1 つのいらだちは、Red gate のツールには、関連するビューまたは udf に SCHEMABINDING をドロップして、単に制約の変更をチェックする習慣があることです。
インスピレーションを得るために、Martin Fowler の「Evolutionary Database Design」を読むこともお勧めします。
ソース管理 (CVS、Git など) に簡単に保存できるので、いつ変更が行われたかを比較して確認できます。
私は展開用の diff ベースのツールを信用していません。vsdbcmd .schema ファイルも差分ベースであるため、これにはそれらが含まれます。前回、コピー/ドロップ/名前変更を介して1.5 TBのテーブルを変更することを喜んで提供する差分ツールを使用しようとしました...
私のアプローチは、展開されたスキーマを v. から v. に移動するアップグレード スクリプトNを常に使用することですN+1。このようにして、アップグレードがどのように行われるかを正確に把握し、操作が不可能な場合 (2 週間続くデータのサイズのコピー操作が必要になる...)、それができないことを知り、コードの変更を計画します。 v. Next のリリースに合わせて。
SQL Server (2005/2008/Azure) のbsn ModuleStore (およびその他) の適切な DB スキーマのバージョン管理に関連する問題に対処しようとするオープンソース (LGPL の下でライセンスされた) ツールセット プロジェクトがあります。
基本的に、ツールセットのスタンドアロン部分は、DB スキーマの SQL Server DB オブジェクトを標準の書式設定が適用されたファイルにスクリプト化するため、オブジェクトが実際に変更された場合にのみファイルの内容が変更されます (VS によって行われるスクリプト化とは非常に対照的です)。 、実際には同一であっても、すべてのオブジェクトを変更済みとしてマークし、スクリプトの日付などもスクリプト化します)。
しかし、.NET を使用する場合、ツールセットはそれを超えて、SQL スクリプトをライブラリまたはアプリケーションに (埋め込みリソースとして) 埋め込み、埋め込みスクリプトをデータベースの現在の状態と比較することができます。テーブルに関連しない変更 ( Martin Fowler の定義によると「破壊的な変更」ではない変更) は、自動的に、または要求に応じて適用できます (たとえば、ビュー、関数、ストアド プロシージャ、型、インデックスなどのオブジェクトの作成と削除)、および変更スクリプト (手動で作成する必要があります) も同じプロセスで適用できます。新しいテーブルも作成され、必要に応じてそれらの設定データも一緒に作成されます。更新後、変更がコミットされる前に DB のアップグレードが成功するように、DB スキーマがスクリプトと再度比較されます。
アプリケーションで bsn ModuleStore を使用するときに、面倒な SMO 依存関係がないように、スクリプトと比較コード全体が SMO なしで機能することに注意してください。
データベースへのアクセス方法に応じて、ツールセットはさらに多くの機能を提供します。いくつかの ORM 機能を実装し、ネイティブ .NET XML クラスによる XML の透過的なサポートや、として TVP (テーブル値パラメーター) の場合IEnumerable<PocoClass>。
SQL Compare は、適用する前に個別に確認できる SQL 移行スクリプトを生成できますが、ツール内でスクリプトを実行するオプションも提供します。Red Gate は、本番データベースにデプロイする場合は前者の方法を使用することをお勧めします。
データベースのバージョン管理については、SQL ソース管理はほとんどのソース管理システム (SVN、TFS など。ただし、VSS のサポートは廃止されています) をサポートしています。v3 には、作業フォルダーにリンクするオプションがあり、必要に応じて独自のバージョン管理クライアントを使用できます。
展開プロセスの一部として比較ツールを使用して、スクリプトが必要なものが不足しているかどうかを確認し、不足している場合は開発者と話し合います (通常、それは必要なため、展開場所にチェックインされていない違いです。本番環境に移動する必要はありません)。ただし、常にソース管理にあるスクリプトからデプロイします。SQL Compare またはその他の比較ツールに依存している場合、まだ移動してはならないものを移動していることに気付く場合があります。