データ移行システムの比較と選択

データ移行システムの比較と選択

データ モデルは開発プロセス中に変更される傾向があり、ある時点でデータベースに対応しなくなります。 もちろん、データベースを削除することもできます。その後、ORM はモデルに一致する新しいバージョンを作成しますが、この手順では既存のデータが失われます。 したがって、移行システムの機能は、スキーマ変更の結果として、既存のデータを失うことなく、アプリケーション内のデータ モデルと確実に同期されるようにすることです。

この記事では、データベースの移行を管理するためのさまざまなツールについて見ていきたいと思います。 このレビューが同様の選択に直面している開発者にとって役立つことを願っています。

タスク

当社は現在、次世代製品である Docs Security Suite (DSS) の開発を積極的に行っています。 サーバー部分は.Net Coreで記述され、DBMSとしてEntity Framework Coreが使用されます。 アプリケーションを設計するときは、Code First アプローチを使用します。

アプリケーション ドメイン モデルは複数の開発者によって同時に作成され、各開発者がシステムの独自の論理部分を担当します。

前世代の DSS では、移行管理システムとして従来の Entity Framework Migrations (EF 6) が使用されていました。 ただし、これに対していくつかの不満が蓄積されており、その主な不満は、EF にはバージョンの競合を解決するための賢明なアプローチが欠けているということです。 この事実は、サポートの一環としてバグを修正するときに依然として動揺するため、代替オプションを検討することにしました。

議論の結果、移行管理システムに対する次の要件が形成されました。

1. さまざまなDBMSのサポート。 MS SQL Server、PostgreSQL、Oracle が必要ですが、他のものを使用できる可能性があります
2. ORM を使用して作業します。 当初は EF Core を使用する予定でしたが、設計段階では他の ORM を検討する準備ができていました。
3. 移行の自動生成。 Code First の開発を考慮すると、移行を「手書き」する必要は避けたいと考えています。
4. バージョンの競合。 分散開発環境では、マージ時に EF Core で競合が発生する可能性があります。 アプリケーションのさまざまな部分がさまざまな開発者によって作成され、それぞれの作業に多くの時間を費やす必要があるため、これは重大な問題になります。
5. 高度なドキュメントとサポート。 ここでは説明の必要はないと思われます
6. 無料。 システムはそれほど高価でも高額でもありませんが、利便性の点で理想的であるため、基準は条件付きです。また、考慮する準備ができていました

少し調査した結果、次のオプションが見つかり、検討することが望ましいことがわかりました。

1. EF コアの移行
2. DBup
3. ラウンドハウスE
4. ThinkingHome.Migrator
5. 流暢な移行者

そしてもう少し詳しく

EntityFramework コアの移行

当然のことながら、これが最初の主な選択肢でした。 タンバリンをいじらなくてもすぐに使えるネイティブ楽器です。 大量のドキュメント、公式なものかそうでないもの、シンプルさなど。 ただし、従来の EF に関する苦情は、EF Core にも非常に関連しています。

したがって、EF Core の利点が強調表示されます。

• Microsoft サポート、ロシア語を含むドキュメント、巨大なコミュニティ
• CodeFirstに基づいた移行の自動生成
• EF 6 と比較して、EF Core はデータベースのスナップショットを保存しなくなりました。 Code First で EF Core を使用する場合、データベースをデプロイする必要がなくなりました。
• Code First から実行しているため、必要なすべてのデータ アクセス プロバイダーに対して XNUMX 回の移行を実行できます。
• プロバイダに関しては、PostgreSQL がサポートされている、Oracle がサポートされている、など、さらには MS SQL Server もサポートされています 

そしてデメリットも:

• 紛争解決は同じレベルを維持しました。 移行を順序立ててデータベースのスナップショットを更新する必要がある
• 移行が生成されるモデルへの依存性

データベースアップ

dbup.github.io

DbUp は、NuGet によってインストールされる .NET ライブラリであり、変更を SQL Server にプッシュするのに役立ちます。 どの変更スクリプトがすでに実行されているかを追跡し、データベースの更新に必要な変更スクリプトを実行します。 このライブラリは ASP.NET 上のオープン ソース ブログ エンジンのプロジェクトから生まれ、MIT ライセンスの下に存在し、コードは GitHub にあります。 移行は T-SQL を使用して説明されます。

利点は次のとおりです。

• 多数の DBMS (MS SQL Server、PstgreSQL、MySQL) のサポート
• スクリプトは T-SQL で記述されているため、非常に単純に見えます。
• 競合も SQL を使用して解決されます

そして短所:

• さまざまな DBMS がサポートされていますが、Oracle はその中に含まれません。
• ORM と対話しません
• T-SQL スクリプトを手動で記述することは、私たちが目指していたものではありません
• ドキュメントとコミュニティはまあまあですが、SQL スクリプトを書くという点では必要ないかもしれません。

ラウンドハウスE

github.com/chucknorris/roundhouse

この移行管理ツールは、以前のものと同様に Apache 2.0 ライセンスに基づいて配布され、T-SQL 移行エンジン上で実行されます。 明らかに、開発者は快適な開発プロセスを作成することよりも、DBMS サポートに関する技術的問題を解決することを優先したようです。

長所：

• 必要な DBMS (Oracle を含む) をサポート

短所：

• Oracle (および、私たちには関係のない Access) は .NET Core ではサポートされておらず、.NET Full Framework でのみサポートされています。
• ORM では動作しません
• 以前のツールよりもドキュメントがさらに少なくなっています
• 繰り返しになりますが、移行はスクリプトによって記述されます

ThinkingHome.Migrator

バージョン管理されたデータベース スキーマを .NET Core プラットフォームに移行するためのツール。MIT ライセンスに基づいて配布されます。 開発者自身がほぼ XNUMX 年前に最新バージョンについて書いています.

長所：

• .NET Core 向けに設計
• 移行の分岐シーケンスを実装しました
• 移行ログの実装

短所：

• 最後に更新されたのは XNUMX 年前です。 どうやらプロジェクトはサポートされていないようです
• Oracle ではサポートされていません (記事には、.NET Core の安定した実装がないことが原因であると記載されていますが、これは XNUMX 年前の話です)
• 移行の自動生成はありません

全体として、このプロジェクトは、特に発展する場合には有望に見えますが、私たちは今ここで決断を下す必要がありました。

流暢な移行者

github.com/fluentmigrator/fluentmigrator

多くのファンを持つ最も人気のある移行ツール。 Apache 2.0 ライセンスに基づいて配布されます。 説明に記載されているように、これは Ruby on Rails Migrations に似た .NET 用の移行フレームワークです。 データベース スキーマの変更は C# クラスで説明されます。

ここには次のような利点があります。

• 必要な DBMS のサポート
• .NETコアのサポート
• 大規模な開発されたコミュニティ
• 移行間の競合は順番に解決されます。移行の実行順序は指定されています。 さらに、XNUMX つのエンティティの周囲で競合が発生した場合、コードをマージするときに、コードの残りの部分と同じ方法で解決されます。
• 移行が成功した後に実行されるプロファイルがあります。 そして、サービス機能を実行できます。最後の更新は XNUMX か月前です。つまり、プロジェクトは生きています。

マイナス点については、次のとおりです。

• 移行の自動生成はありません
• EFモデルとは関係ありません
• データベースのスナップショットがありません

私たちの選択は何でしたか？

白熱した議論は、移行の自動生成と競合の健全な解決という XNUMX つのパラメータを中心に展開されました。 他の要素はそれほど怖くありませんでした。 その結果、議論の結果に基づいて、チームは新しいプロジェクトで Fluent Migrator を使用することを決定しました。 なぜなら、将来的に紛争を解決することは、より多くの利益をもたらすからです。

所見

もちろん、完璧なツールはありません。 そのため、私たちは自分の「欲しいもの」を優先して選択する必要がありました。 ただし、他のチームや他のタスクの場合は、他の要因が決定的な要因となる可能性があります。 この記事があなたの選択に役立つことを願っています。

出所： habr.com