私が Red Gate で SQL ソース管理を行っていることを前もって開示します。
その変更では、テーブルを再作成する必要があります。デフォルトでは、SSMS ではその変更を保存できません。ただし、そのオプションは SSMS で無効になっている必要があります。[ツール] -> [オプション] -> [デザイナー] -> [テーブルおよびデータベース デザイナー] -> [テーブルの再作成が必要な変更を保存しない] の下にあります。
その機能が無効になっている場合、SQL ソース管理はそれを潜在的なデータ損失の状況として検出し、移行スクリプトを追加するかどうかを確認するように求めます。
チーム内の他の開発者が get latest を介してこの変更を取得すると、ローカル データベースの現在の状態に応じて、SQL ソース管理により、データ損失の可能性が詳細に示されます。唯一の変更が既存のテーブルへの列の追加である場合、変更されていない列のデータは削除されません。
別の DB (例: staging/UAT/prod) にデプロイしていて、SQL Compare がある場合、別の非ローカル データベースに対してこれを実行しようとすると、それを使用して DB に適用されるものを正確に確認できます。デプロイ スクリプトの作成オプションを選択すると、実行前に SQL のサニティ チェックを行うことができます。
あなたが言うように、テーブルの最後に列を追加すると再構築の必要がなくなるため、列の場所を気にする必要がない場合は、おそらくこれを回避する最も簡単な方法です。
または、移行スクリプトを次の場所に追加できます。
- 一時名を使用して、新しい構造を持つ新しいテーブルを作成します
- 既存のデータを一時テーブルにコピーします
- 既存のテーブルを削除する
- 新しい一時テーブルの名前を元の名前に変更します
ブランチとマージ、および DVCS システムをより適切にサポートするために、移行の仕組みを変更するベータ機能である Migrations v2 について言及されています。http://www.red-gate.com/migrationsを参照
バージョン 1 移行スクリプトを v2 移行スクリプトに変換するには、いくつかの変更が必要です。かなり些細な変更です。現在、これを文書化する作業を行っています。この変更に関する詳細情報が必要な場合は、Google グループでお問い合わせください。https://groups.google.com/forum/#!forum/red-gate-migrations