web-dev-qa-db-ja.com

リリース前にデータベースの移行をマージする必要がありますか？

開発プロセス中に、多くの移行が表示される場合があります。それらをすべてマージする代わりに、それらを保持する意味はありますか？

簡単な例を見てみましょう。

開発中に、新しいモデルPersonを導入します。

public class Person {
    public int Id { get; set; }
    public string Name { get; set; }
}

移行＃1は、データベースに2つのフィールドを持つ新しいテーブルPersonsを作成します。

後で、別のフィールド-Surnameが必要だと判断しました。移行＃2では、新しいフィールドを追加してテーブルを変更します。

後で新しい関連モデルを導入することを決定したため、Migration＃3は新しいテーブルを作成し、外部キーを追加してPersonsを変更します。

その後、Surnameを削除することにしました。移行＃4では、列を削除してテーブルを変更します。

その後、Personsの複数形の名前をPersonに変更することにしました。 Migration＃5は、すべての外部キーを削除し、後でテーブルの名前を変更して、新しい外部キーを作成します。

最終的に、最終リリースでは不要ないくつかのフィールドを作成および削除するための前向きな作業を実行する多数の移行があります。これらのフィールドは、他のいくつかの可能なマイグレーションアクションとともに、開発履歴の一部にすぎませんが、実際には必要ありません。

したがって、データベースを最初の状態にロールバックし、すべての移行を削除してから新しいデータベースを生成すると、データベースを最終的な状態にするために必要なアクションのみを実行し、移行の膨大な数を減らし、たった1つの単純な移行への過剰なアクション。

それは良い考えですか、それともアンチパターンと見なされますか？

databaseentity-frameworkmigrationefcore
4
Exerion

マージされた移行が中間状態のデータベースにヒットしないことが100％確実である限り、これは問題ありません（たとえば、Surname列は存在しますが、そうではありません）。

これは、展開プロセス（特に移行の展開）をどの程度適切に制御するかに依存します。これは必ずしも本番リリースに限定されているわけではないことに注意してください。また、テスト環境にどの中間状態があるかを知る必要があります。また、ローカルテスト目的で各開発者が独自のデータベースを持っている大規模な開発チームがある場合も、これは可能性があります。さまざまな開発環境の潜在的な状態の影響を受けます。

2
Doc Brown

移行は、システムの展開時に自動的に適用されます。 SQLのDDLコマンドがインストールにかかる時間を支配する可能性は非常に低いため、適切なことは、システムのこの低レベルの詳細について心配しないことです。これらをすべて統合すると、作業が必要になり、結果には実質的に何も貢献しません。そのため、プロジェクトで絶対に急ぐ必要がなくなるまで、優先度の最も低いタスクを残しておく必要があります。

1
Kilian Foth

大企業での展開のために移行がロールアップされるのを見てきました。私はそれをアンチパターンとは呼びません。

EFは少し変わったケースですが、一般的には、DBマイグレーションに非常に注意する必要があります。私が見た最も一般的なアプローチは、それらを再生してから手作りすることです。

これにより、本番と同様のデータ量のDBに対してそれらをテストして、それらが正しく機能し、パフォーマンスの問題を引き起こさないことを確認できます。また、適用できるロールバックスクリプトが機能していることを確認する必要があります。

実際、それらをすべてマージした後で、それらを再度分割して、下位互換性やその他の要件を持つ段階的なロールアウトを可能にすることができます。

オブジェクトを更新するだけでEFにProduction DBの処理方法を理解させる勇敢な開発者です。 （tbf MSはかなりうまくいきますが）

1
Ewan