アプリケーションで適切なデータベース開発プロセスを見つけようとしています。私は Visual Studio データベース プロジェクトを Post/Pre デプロイ スクリプト (非常に優れた機能)、Entity Framework Database First アプローチ (ソース管理下に配置されたデータベースの変更ごとに個別のスクリプトを使用) で試しましたが、現在は Entity Framework Code First を扱っています。アプローチ。私はそれが与える可能性に本当に感銘を受けていると言わざるを得ませんが、開発中にモデルの変更を管理する方法を理解しようとしています. 社内に次の環境があると仮定します。
LOCALHOST - 単一の開発者ごと、TEST - テスト用の SQL Server データベースを備えた単一のマシン、PRODUCTION - クライアントが使用する SQL Server データベースを備えた単一のマシン
これで、アプリケーションの作業中にコードが変更されるたびに、アプリケーションをテストするたびにデータベースを削除して再作成しても問題ありません (LOCALHOST および TEST 環境の場合)。データベースにテスト データをシードする適切なデータベース初期化子を作成しましたが、これにはかなり満足しています。
ただし、モデルが変更されたときの新しいビルドごとに、データ全体が失われないように、PRODUCTION データベースの変更を処理したいと考えています。それで、Visual Studio 2012 には「SQL スキーマ比較」ツールがありますが、製品開発用のデータベースのすべての変更を管理するのに十分ではないのではないかと思っています。{local} データベース スキーマを PRODUCTION スキーマと比較して、すべての変更を適用するだけでよいのですか?
ここで、Code First Migrations のポイントは何ですか? それを介してデータベース内のすべての変更を管理する必要があるのはなぜですか? 私が見つけた唯一の理由は、あらゆる種類の「INSERT」および「UPDATE」コマンドを実行できるようにすることです。ただし、データベースが正しく設計されていれば、これらのコマンドを実行する必要はないと思います。(別の議論のトピックなので、詳細には立ち入りたくありません)。とにかくお聞きしたいのですが、Code First + Schema Compare パターンに対する Code First Migrations の本当の利点は何ですか?