web-dev-qa-db-ja.com

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

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

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

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

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

schemassdtmigration
11
Neo

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

17
Ed Elliott

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

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

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

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

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

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

2
a_vlad

私は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を使用するのはかなり簡単な決定です。

2
VenVig