スキーマの移行：SQL ServerデータツールとLiquibaseおよびFlyway

これは馬鹿げた質問のように思えるかもしれませんが、私はスキーマ移行のためのオープンソースソリューション、つまりLiquibaseとFlywayを検討してきました。

ただし、上司から、SQL Serverデータツール（SSDT）でも同じことができると言われました。同意するかどうかはわかりませんが、インターネット上でLiquibaseやFlywayと直接比較するものはほとんどありません。

SSDTはSQL Serverの開発、データモデリング、および設計ツールであり、スキーマ比較（およびそのスクリプトの生成）とソース管理もサポートしていると私は考えています。スキーマ移行のいくつかの側面でLiquibase / Flywayと一部重複する可能性がありますが、別の問題に取り組みます。しかし、全体的なスキーマ移行ツールとして、LiquibaseとFlywayは完全に専用のツールですが、SSDTはデータベースの設計と開発に適しています。

比較がないと言うだけでSSDD自体はスキーマ移行ツールではないとしても、どんな意見でも大歓迎です。

SSDTはLiquibase / Flywayに匹敵します。Liquibase/ Flywayの機能は同じですが、アプローチは異なります。SSDTには開発環境があり、定義に移動したり、参照やインテリセンスを見つけたり、プロジェクトをdacpacにコンパイルしたり、そのdacpacをデータベースに展開したりできます。

SSDTの方法（およびredgate sql compareの方法）でデロイメントを行うには、次のようなテーブルを変更する場合に必要なものを宣言します。

create table a(id int)

次のようなテーブルに：

create table a(id int, another_column varchar(12))

SSDTを使用すると、テーブル定義を2番目の定義に変更し、SSDTがそれをアップグレードする方法を心配するようにします（テーブルの変更、列の追加、または列の順序の変更を行うことができるため、テーブルを再構築する必要があります）。

Liquibase（DbUp、ReadyRoll、手動メソッドなど）では、この場合、自分で変更テーブルを作成し、スクリプトを正しい順序で実行する必要があります。このシナリオを検討してください。

1. リリース1-テーブルに列helloを作成する
2. リリース2-hello列の名前をjoe_blogsに変更
3. リリース3-列の名前をjoe_blogsからhelloに変更
4. リリース4-列joe_blogsを作成する

リリースのいずれかを逃した場合、次のリリースは続行できません。

アップグレードスクリプトの利点（Liquibase、DbUpなど）：

• スクリプトを完全に制御できます
• DBA /開発者はこれに慣れています

比較/マージの利点（SSDT、Redgate SQL Compare）：

• アップグレードスクリプトを記述する必要はありません
• 特定のバージョンにアクセスするのは簡単です。そのバージョンを比較してマージするだけです。

アップグレードスクリプトの欠点：

• 順番に実行する必要があります
• ミスを犯さずに人間に依存する
• 特に変更が多い場合は遅くなる可能性があります
• チームが非常に規律のあるデータベースでない限り、さまざまな環境（開発、テスト、ステージング、製品など）で同期が取れなくなることが多く、テストが無効になります。
• リリースのダウングレードとは、すでに書いたすべてのスクリプトの逆を書くことを意味します

比較/マージを使用することの欠点：

• ツールは100％信頼されていない、おそらく不公平
• SSDTには作業プロジェクトが必要です。多くのデータベースには、実際にコンパイルまたは実行されないコードがあります（ドロップされたテーブルではなくプロシージャなど）。これは、継承した約8/10のデータベースで確認されています。
• 多くのDBA /開発者は、SSMS /メモ帳での開発をあきらめることをためらっています

個人的には、私はSSDTがプロの開発環境だと本当に思っています。つまり、それ自体が目的に過ぎないアップグレードスクリプトを書くのではなく、有用なコードとテストを書くことに集中できるということです。

あなたはそこに行くので、あなたは意見を求めました:)

ed

私は予備の回答を補充するだけです。

中心的な場所のFlyway Webサイトで説明されている最大の違い：

1つの問題のみを解決し、それをうまく解決します。Flywayはデータベースを移行するので、もう心配する必要はありません。

Visual Studio + SSDT + SSIS =フルパワーETLツール、唯一の実際の欠点-Windowsでしか機能しない実行パッケージにはWindows + SQL Serverが必要ですが、ほとんどすべてのソースで機能します。

データの転送/移行-市場に出回っている多くの製品。コマーシャル、オープンソース、コミュニティ/エクスプレスなど

移行コードの場合-すべてはそれほど良くありません。ソフトウェアが「トリガー、プロシージャ、関数を問題なく変換する」ことを約束しているとしても、実際には-シンプルで、ほとんどのコードの移行-手動。

私はSqlサーバーデータツールとflywayの両方を使用してきました。SSDTを使用すると、次の利点があります。

1. データベースプロジェクトをコンパイルできます。つまり、ビュー、関数、またはストアドプロシージャによって参照されている列を削除する心配はありません。これは素晴らしい機能です。以前は、リリース後に初めてこのようなミスが見つかりました。

2. ビルドが成功すると、SSDTは「DACPAC」と呼ばれるものを生成します。これをバージョン付きのmsiと考えてください。

3. たとえばバージョン5の特定のdacpacは、Dacpacバージョン1、2、3、4または6、7、8などのデータベースに適用できます。1〜4に適用すると、データベースがアップグレードされます。6,7などに適用した場合、DBはダウングレード/ロールバックされます。データが失われると警告が表示され、抑制できます。そのため、flywayなどの他のツールでは使用できない優れたロールバック機能を利用できます。flywayでは、ロールバック用の新しいスクリプトセットを提供する必要があります。

4. DACPACはすべての変更を1つのトランザクションで適用します。つまり、アップグレードで5つのテーブル変更があり、そのうちの1つが失敗した場合、トランザクション全体がロールバックされます。Flywayもこれをサポートしていますが、すべてのファイルに対応しています。

ただし、SSDTとDACPACはMicrosoft SQL Server固有です。flywayは、さまざまなデータベースに使用できます。

つまり、SQL Serverのみを使用している場合、SSDTとDACPACを使用するのはかなり簡単な決定です。