1

実稼働サイトで Entity Framework 4.3 の移行を使用することを検討しています。以下が私の懸念事項です。

なんらかの理由で移行が失敗した場合は、すべてのステートメントをロールバックし、サイトをダウン状態にして、問題を解決しようとしている間、ユーザーがサイトを使用できないようにします。唯一のことは、移行ファイルがアセンブリでコンパイルされるため、データベースに対して手動でスクリプトを実行する方法にフォールバックできないことです。移行ファイルと sql スクリプト ファイルの両方を別々に追跡できましたが、その時点で移行を使用する理由はまったくありません。

職場では、スクリプト ファイルはサイトの (誰も参照できない) SQL フォルダーに格納されます。以前に実行されたスクリプト ファイルがデータベースに登録されます。新しいスクリプト ファイルがフォルダーに表示される (データベースには存在しない) 場合、ユーザーが管理者である場合は DB ポータルにリダイレクトされ、それ以外の場合はメンテナンスのためにサイトがダウンします。ポータルからスクリプトを実行しようとして失敗した場合は、新しいスクリプトを取得して Express Studio 内で手動で実行しようとします。これは10年以上にわたって機能しています。より良い方法が到着したかどうかを確認するために、移行を調査しているだけです。それはそれのように感じません。より良い方法があれば教えてください。それが移行ではない場合、それは何ですか。

4

1 に答える 1

3

本番環境で自動移行を使用することは絶対にありません。実際、私は自動移行をまったく使用できない制御フリークです。すべてのデータベース (開発者自身の個人用、テスト環境、本番環境) がまったく同じ更新シーケンスを経ていることを確認するために、コード ベースの移行を好みます。

各移行ステップに名前が付けられるコードベースの移行を使用すると、テスト環境と本番環境を持ち上げるときに使用する個別の移行スクリプトを生成できます。できれば、実際の本番環境で実行する前に検証するために、データベースのコピーで実行する必要があります。

後で追加

EF 移行が自動的に何かを行うのを防ぐために、カスタムの初期化子戦略を使用できます。私のブログまたは運用データベーススタック オーバーフローへの EF Code First アプリのデプロイに関する質問を参照してください。

于 2012-03-07T20:44:30.110 に答える