SQL Source Control (3.0) と SQL Compare (10.1) の最新バージョンの変更を反映するために、以下の元の投稿を更新しました。
この質問は 1 年以上前に尋ねられたので、私の回答はあなたにとってあまり役に立たないかもしれませんが、現在 SSC を評価している可能性のある他の人のために、私は 2 セントを投じると思いました. SQL ソース管理 (SSC) を使い始めたばかりで、全体的にこれまでのところかなり満足しています。ただし、特に共有データベース環境で作業している場合 (すべての開発者がローカルで作業しているのとは対照的に)、特に同じデータベース内のオブジェクトが開発チーム間で無計画に分割されているレガシー環境で作業している場合は、いくつかの癖があります。
私たちの組織で製品をどのように使用しているかを簡単に説明すると、私たちは共有環境で作業しており、全員が同じ開発データベースに変更を加えているため、共有データベースをソース管理リポジトリにアタッチしました。各開発者は、SQL Server Management Studio (SSMS) を使用してデータベース内のオブジェクトに変更を加える責任があり、変更が完了したら、変更をソース管理にコミットできます。ステージングにデプロイする準備ができたら、ビルド マスター (私) はデータベース コードの開発ブランチをメイン (ステージング) ブランチにマージし、データベースのメイン ブランチ リポジトリ バージョンをソースおよびライブ バージョンとして使用して SQL Compare を実行します。 SQL Compare は、ステージング環境に加えられた変更をデプロイするために必要なスクリプトを生成します。本番環境へのステージングは、同様の方法で機能します。注意すべきもう 1 つの重要な点は、同じデータベースを他の開発チームと共有しているという事実を考慮して、SSC の組み込み機能を使用して、名前、タイプなどでデータベース オブジェクトのフィルターを作成できるようにすることです。他のすべてのオブジェクトを除外して、特定のチームのオブジェクトにフィルターを設定して、展開を行うときに他の開発チームの変更を誤ってコミットしないようにします。
したがって、一般的にセットアップして使用するのは非常に簡単な製品であり、SSMS で常にライブ オブジェクトを操作しているため、同期が取れなくなるリスクがある別のソース リポジトリに保存された切断されたスクリプト ファイルとは対照的に、非常に優れています。 .また、SQL Compare が配置スクリプトを生成するため、自分でスクリプトを作成する場合のようにエラーが発生することを心配する必要がないため、これも優れています。また、SQL Compare は非常に成熟した安定した製品であるため、適切なスクリプトが作成されることを確信できます。
そうは言っても、これまでに遭遇した癖のいくつかを以下に示します。
- SSC は、ソース管理リポジトリと同期していないデータベース項目を追跡するために、db サーバーと通信するという点で、すぐに使用できるようになっています。数ミリ秒ごとにポーリングし、SSC を使用して同じデータベースに対して作業している複数の開発者を追加すると、データベース管理者があまり満足していないことが想像できます。幸いなことに、オブジェクトが変更されたときの応答性の高い視覚的な通知を犠牲にするという代償を払ってはいますが、ポーリング頻度をより許容できるレベルに簡単に減らすことができます。
- オブジェクト フィルタリング機能を使用すると、SSMS のオブジェクトを見ても、どのオブジェクトがフィルターに含まれているかを簡単に判断できません。そのため、オブジェクトがソース管理下にあるかどうかはわかりません。Visual Studio とは異なり、ソース管理されたオブジェクトを示すためにアイコンが使用されます。
- オブジェクト フィルタリング GUI は非常に扱いにくいです。レガシーデータベース環境で作業しているため、現在、チームが所有するオブジェクトと他のチームが所有するオブジェクトとの間に明確な分離がありません。他のチームの変更を誤ってコミット/デプロイするのを防ぐために、所有する特定のオブジェクトを明示的に含めるようにフィルタリング スキームを設定しました。ご想像のとおり、これは非常に面倒です。フィルターを編集する GUI は一度に 1 つのオブジェクトを入力するように設定されているため、特に初めて環境を設定しようとすると、非常に面倒になる可能性があります (最終的にはこれを行うアプリケーションを作成します)。今後は、オブジェクトのフィルタリングをより容易にするために、アプリケーション用の新しいスキーマを作成します (いずれにせよより良い方法であることに加えて)。
- 共有データベース モデルを使用すると、開発者は保留中の変更をソース管理データベースにコミットすることができます。変更が自分のものではない場合でも同様です。 SSC は、一連の変更をチェックインしようとすると、これらの変更が自分のものではない可能性があるという警告を表示しますが、それ以外は自分で行っています。実際、これは SSC の最も危険な「癖」の 1 つだと思います。
- SQL Compare は現在、SSC によって作成されたオブジェクト フィルターを共有できないため、SQL Compare で一致するフィルターを手動で作成する必要があるため、これらが同期しなくなる危険性があります。最終的には、下層の SSC フィルター ファイルから SQL Compare プロジェクト フィルターにフィルターをカット アンド ペーストして、扱いにくいオブジェクト フィルタリング GUI を処理することを回避しました。 SQL Compare の次のバージョンでは、SSC とフィルターを共有できるようになると思いますので、少なくともこの問題は短期的なものに過ぎません。 (注:この問題は、SQL Compare の最新バージョンで解決されています。SQL Compare は、SSC によって作成されたオブジェクト フィルターを使用できるようになりました。)
- SQL Compare は、直接起動した場合、SSC データベース リポジトリと比較することもできません。 SSMS 内から起動する必要があります。 SQL Compare の次のバージョンでこの機能が提供されると思いますが、これも短期的な問題です。 (注:この問題は、最新バージョンの SQL Compare で解決されています。)
- SQL Compare は、ターゲット データベースをある状態から別の状態に取得するための適切なスクリプトを作成できない場合があります。これは通常、空でない既存のテーブルのスキーマを更新する場合に発生します。手動スクリプトを作成し、プロセスを自分で管理します。幸いなことに、これは SSC の次のリリースで「移行スクリプト」によって対処される予定です。製品の初期リリース バージョンを見ると、この新機能の実装はよく考えられて設計されているようです。 (注:移行スクリプト機能は正式にリリースされました。ただし、現時点では分岐はサポートされていません。移行スクリプトを使用する場合は、SQL を実行して元の開発コード ブランチと比較する必要があります...変更をチェックインしました...これは非常に扱いにくく、この制限を回避するためにビルド プロセスを理想的とは言えない方法で変更せざるを得ませんでした。うまくいけば、これは将来のリリースで解決されるでしょう。)
全体として、私はこの製品と、ユーザーからのフィードバックに対する Redgate の対応と製品の方向性に非常に満足しています。この製品は非常に使いやすく、よく設計されています。次の 1 つか 2 つのリリースで、必要なもののすべてではないにしても、ほとんどのものが提供されると思います。