ここにはたくさんの質問があります。FluentMigrator を中心に質問にお答えします。
バージョニングによってデータベースの更新を最初に作成してから維持する方法ですか。
FluentMigrator は、データベース スキーマをバージョン管理する方法です。誰もが何らかの方法でそれを行います。手動で、SQL スクリプトを使用して、SqlCompare や Visual Studio データベース プロジェクトなどのツールを使用して。これらの方法はすべて簡単に台無しになります。新しいバージョンをリリースするときに間違いを犯してシステムをクラッシュさせるのはとても簡単です。移行は、これを処理するためのより良い方法です。
FluentMigrator を使用すると、スキーマへの変更をコードとして定義できます。これは通常、他のコードの変更と共にソース管理にチェックインされます。つまり、システムのバージョン 1.XX にはバージョン 123 のデータベースが必要です。つまり、コードを以前のバージョンにロールバックすると、ロールバックするデータベースのバージョンもわかるということです。
データベース スキーマを最初から作成する場合と、既存のデータベースのスキーマのバージョン管理を開始する場合の両方に使用できます。
移行は、データベース スキーマへの変更を説明する方法です。FluentMigrator は VersionInfo テーブルを作成し、適用後に移行の一意の ID (バージョン番号) を保存します。
たとえば、ID 1 と ID 2 の 2 つの移行があるとします。最初の移行を実行すると、ID 1 が VersionInfo テーブルに格納され、そこを見て、データベースのバージョンが 1 であることがわかります。そのバージョン 2 はまだ適用されていません。
テストから本番に変更をプッシュする場合、または本番にデータベースの複数のコピーがある場合に、データベース スキーマのバージョンを知ることができると非常に便利です。たとえば、世界中にオフィスを持つ顧客がいて、各オフィスには独自のデータベースのコピーがあり、それらはすべて異なるバージョン上にあるとします。データベースのバージョンを知らなければ、安全に更新することは非常に困難です。
ほとんどの場合、VersionInfo テーブルを実際に調べる必要はなく、FluentMigrator がこれを自動的に処理します。アセンブリと Migrations を VersionInfo テーブルと比較し、まだ適用されていない変更を特定して実行します。
最初の移行 (またはデータベースの初期バージョン) には、必要なすべてのテーブル、リレーションシップ、およびプロパティが含まれます (流暢に実行するか、スクリプトで SQL のチャンクを使用して実行します)。
出発点はあなた次第です。現在のデータベースから生成した SQL スクリプトである最初の移行を行うことができます。FluentMigrator.T4などの contrib プロジェクトの 1 つを使用して、Fluent Migration を生成することもできます。または、既存のデータベースが開始点であると判断し、そのコピーを保存してバージョン 1 として復元できるようにすることもできます。
多くのレガシー データベースに FluentMigrator を導入しましたが、大きな問題はありませんでした。
変更をデータベースにプッシュする場合は、新しいテーブルの追加やフィールドの変更など、新しい移行方法 (上と下) を作成します。
はい、アップは移行で指定された変更を適用するために使用され、ダウンはそれをロールバックします。つまり、Up でテーブルを作成し、Down でテーブルをドロップできます。
これらの移行のいずれかを展開するには、コマンド ラインを使用して、移行を含む dll、接続文字列、および必要なバージョンを指定します。
移行の実行に使用できるランナーは 3 つあります。コマンド ライン ランナー、Nant タスク、および MSBuild タスク。通常、ビルド スクリプトの一部として実行されます。
MigrationRunner クラスは、コードでも使用できます。独自のランナーを構築したい場合、または他のニーズがある場合 (データベースを動的に構築したり、新しい移行が追加された場合にデータベースを自動的に更新したりする場合など) に、これを行うことができます。
かなり複雑なデータ モデルのセットがある場合、そのすべての移行定義を作成するのはかなり難しく、時間がかかりませんか?
私はすでにこれにほとんど答えました。通常、データベース用の SQL スクリプトを生成するのは非常に簡単です。Sql Server の場合、大規模なデータベースであっても、スクリプトを生成するのに 1 分もかかりません。このスクリプトを .sql ファイルに保存し、Execute.EmbeddedSqlScript 式を使用して最初の移行として実行できます。それは御馳走になります。
nHibernate/fluent を使用すると、モデルとマップ ファイル以外を定義する必要なく、データベースのテーブルを簡単に生成できることを私は知っています。この構成を Migrator/Versioning と互換性を持たせる方法はありますか?
現時点では、そのような統合はありません。実際には、少なくとも、それを見逃すことはありません。Fluent NHibernate と FluentMigrator を接続することについていくつかの議論がありましたが、それは大変な作業になるでしょう。EF Code First の移行のように、スキャフォールディングでモデルに変更を加えることができます。ただし、現時点ではロードマップにはありません。
nhibernate/fluent がデータベースの生成を担当している場合、必ずしもテーブルのすべての側面を定義する必要はありません。慣例またはマッピングファイルを介して行われます。マイグレータでは、このレベルの詳細を定義する必要がありますか?
はい、その詳細レベルで定義する必要があります。FluentMigrators の移行は、SQL に変換されるスキーマの変更を定義するための DSL (独自の小さな言語) です。Execute.Sql 式を使用して、SQL を直接記述することもできます。Entity Framework の移行には、長所と短所の両方を持つ、そのような統合があります。
開始するための詳細なヘルプについては、 wikiまたはここ、ここ(パート 1)、またはここ(パート 2) のいずれかのチュートリアルを確認してください。