Visual Studio データベース プロジェクトを使用して、ソース管理された静的データをデータベースにどのように入力しますか? 私は以下の 3 つの戦略をすべて試しましたが、それぞれが最後の戦略よりも徐々に優れていることがわかりました。戦略 3 を使用していますが、完全には満足していません。別の選択肢はありますか?
挿入スクリプトを「Data Generation Plans」フォルダーに配置します。「Script.PostDeployment.sql」ファイル内のスクリプトを参照して、デプロイメント プロセスに含めます。
-- 利点: 単純
明快 -- 欠点: slooooooow
-- 欠点: 後続のデプロイでは、最初に静的データを削除するか、データが存在しないことを確認する必要がある => 非効率的最初は、最も便利な方法 (SSMS 編集テーブル機能など) を使用して、データをデータベースに挿入します。bcp コマンド ライン ユーティリティを使用してそのデータを抽出し、一連のデータ ファイルを作成してプロジェクトに追加します。各データ ファイルに対して「一括挿入」ステートメントを実行する「Scripts.PostDeployment.sql」ファイルで参照されるスクリプトを作成します。
-- 利点: insert ステートメントよりもはるかに高速です
-- 利点: SSMS 編集テーブル機能を利用できます
-- 欠点: 各一括挿入ステートメントには、データ ファイルの完全修飾ファイル名が必要です。 :\Projects\Dev\Source\foo.dat" の場合、リモート開発マシンもその場所に配置する必要があります。そうしないと、一括挿入ステートメントが失敗します
-- 欠点: 後続のデプロイで一括挿入ステートメントを実行する前に、既存の静的データを削除する必要があります配置中に一時テーブルを作成して静的データを保持し、SQL マージ ステートメントを使用してこれらのテーブルをターゲット テーブルと同期します。これらのブログ投稿のいずれかを参照してください。
-- 利点: SQL マージは問題に対して完璧なセマンティクスを持っているようです
-- 欠点: この戦略のロジックは各ファイルで繰り返されます -- 欠点: テーブル定義は SQL マージ ファイルの一時テーブルとして繰り返されます
優れた代替戦略はありますか? 戦略 1 は遅すぎたので断念しました。完全修飾ファイル名の問題があるため、戦略 2 は嫌いです。戦略 3 には満足していますが、興奮はしていません。ベスト プラクティスはありますか?