私は4.3.1でEntityFrameworkの移行を検討し始めました。いくつか質問があります：
開発中に何が好ましいですか？データベースを常に削除して再作成してから再シードする必要がないのはなぜですか。コードファーストマイグレーションを使用する場合、最初にデータベースをシードしてから、各マイグレーションにシードメソッドを追加して、新しいデータのみを追加することを選択できますか？自動移行を使用する場合、同様のことを行うことは可能ですか？つまり、最初にシードしてから、必要に応じてシードしますか？
開発中に移行を使用する利点は何ですか？実際に必要なのは、本番環境に移行するときだけです。したがって、最初のスクリプトを作成してから、移行ごとにスクリプトを作成する必要があります。本番環境に移行するときにのみ移行を使用し、その時点で初期スクリプトを作成して、その時点以降の移行履歴を維持することは可能でしょうか。
私たちの場合、Migrations の使用を開始しました。なぜなら、私たちの会社では、開発者が DB を作成するために必要な権限を持っていないためです。そのため、DB を数回ドロップして、データベースに問い合わせる必要があったという面白いシナリオにつながりました。管理者は毎回再作成する必要があります...
私の意見では、毎回再作成するよりも、DB を段階的に拡張する方が簡単なようです。プロパティが追加、削除、または変更されるたびに DB を削除して再作成する必要があるとしたら、それが終わることはありません。
おそらく手動で移行ファイルを作成する場合を除き、増分シードの可能性はまだ見ていません。
移行には、特定のバージョン (前方または後方) に移動する可能性があり、移行から SQL スクリプトを生成することができます。
したがって、基本的には、手動で移行 SQL スクリプトを作成する必要はなくなりました。Migrations に任せることができます。