SQL Source Control は SSMS にプラグインし、データベースをバージョン管理システムに接続します。これにより、データベース スキーマをバージョン管理し、Redgate の信頼できる比較エンジン SQL Compare を使用してデプロイすることができます。
最新のリリース（今週出荷！）では、マイグレーションスクリプトが改良されています。マイグレーションスクリプトは、SQL Compareによって生成されたデプロイメントスクリプトをオーバーライドするために独自のSQLを書くことができ、データを失うリスクなしにチームメイトがソースコントロールから最新の変更を取得することが可能になります。
しかし、ここでは、一般的なシナリオを使用して、どのように動作するかを説明したいと思います。
How to avoid data loss when renaming a table
影響を受ける可能性のある一般的なタスクには、列やテーブルの分割や結合、列への NOT NULL 制約の追加、列のデータ型やサイズの変更、テーブルの名前の変更などがあります。
開発データベース上でテーブルの名前を変更した場合、SQL Source Control はこの変更を DROP および CREATE として解釈します。
このデータ損失を回避するには、sp_rename ストアド プロシージャを使用してテーブルの名前を変更する移行スクリプトを記述します。
テーブルの名前を変更したら (この例では users から customers)、次のステップは、SQL Source Control の [Commit changes] タブを使用してソース コントロール システムに変更をコミットすることです。
[移行]タブの[コミットされていないスキーマ変更の置き換え]では、チェックボックスを使用して関連するスキーマ変更を選択します。
この例では、テーブルの名前を変更したものの、まだコミットしていないため、コミットされていないスキーマの変更を置き換えています。
[スクリプトの生成]をクリックすると、SQL Source Control はコミットされていない変更に基づいて移行スクリプトを生成し、自動的に生成された DROP および CREATE ステートメントを置き換えることができるようになります。
この場合、次のような SQL を使用します：
EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO
ここで customer テーブルの同義語を使用することで、テーブルが古い名前で参照される問題を回避できます。
保存して閉じると、この移行スクリプトが行われた変更を置き換えます。
[コミット]タブに戻ると、関連するスキーマの変更を含む移行スクリプトが下に表示されます。
これで、変更を展開する準備が整いました。 SQL Compare を使用している場合、移行スクリプトはデプロイ中に自動的に実行され、DROPCREATE ステートメントの代わりに sp_rename ストアド プロシージャを使用して、もともと SQL Compare エンジンによって生成されます。