c# - リセット - update database init




EF移行で運用データベースを更新しても大丈夫ですか? (3)

さて、とにかく答えてみます。 いいえ、実稼働環境でCode First Migrationsを使用しない理由はありません。 結局のところ、この使いやすいシステムのすべてを理解できない場合のポイントは何ですか?

私がそれで見た最大の問題は、あなたがすでに指摘したように、あなたがどんなシステムでも持つことができるすべての問題です。 チーム全体(該当する場合はDBAを含む)が参加している限り、移行を通じてEFがスキーマを管理できるようにすることは複雑ではないため、従来のスクリプトベースの管理よりもエラーが発生しにくいと思います。 実稼働システムで移行を実行する前にバックアップを作成しますが、それでもあなたはそれを行います。

DBAがVisual Studioからの移行を実行できないということは何もありません。 データベースレベルの権限でアクセスをロックダウンし、実際の操作を実行する前に(必要に応じて -Script を使用して有用なSQLエクスポート形式で)移行を確認できます。 その後、それらはまだ制御されていますが、コードファーストの移行を使用できます。 地獄、彼らはそれを好きになるかもしれません!

更新:SPROCとTVFが作成されたので、移行でも同様に処理しますが、実際には Up()DbMigration.Sql() 呼び出しを使用してストレートSQLステートメントで実行され、逆に Down() (単純なSPROCに CreateStoredProcedureDropStoredProcedure を使用することもできますが、SQLで本体自体を定義する必要があると思います)。 それは警告だと言えると思います。 包括的なデータベース全体を純粋にC#で記述する方法はまだありません。 ただし、SQLスクリプトを含む移行を使用して、スキーマ全体を管理できます。 このプロセスから得られた利点の1つは、構成ファイル自体のXML変換と組み合わせた単純な String.Format を使用して、スキーマオブジェクト名(たとえば、本番と開発用の異なるサーバー名)にC#構成ファイルを使用できることです。

このブログ投稿に よると EF Migrationsを使用しているほとんどの企業は、EF Migrationsで本番データベースのデータベーススキーマを更新していないと思われます。 代わりに、ブログ投稿の著者は、展開プロセスの一部としてスキーマ更新スクリプトを使用することを推奨しています。

私は数年前からスキーマ更新スクリプトを使用してきましたが、それらが機能している間、次の理由で将来的にはEF移行を使用することを計画していました。

  • 迅速な展開、ダウンタイムの削減
  • より簡単な展開手順
  • T-SQLを使用した場合よりも既存のデータの移行がはるかに簡単
  • 適用されるのを待っている変更のよりわかりやすい構文(従来の環境でのクリーンなC#構文を使用したDbMigrationクラスと不格好なT-SQL移行スクリプト)。
  • 新しいソフトウェアバージョンの展開が失敗した場合、古いdbスキーマへの簡単で高速なダウングレードパスがあります。

EFを使用して実稼働DBを移行することを禁止すると考えられる理由の1つは、DBスキーマが開発者ではなくDBAによってのみ変更された場合です。 ただし、私はDBAと開発者の両方であるため、私の場合はこれは重要ではありません。

それでは、EFを使用して本番データベースを更新するリスクは何ですか?

編集:solomon8718がすでに提案したように、私は常に本番データベースの新しいコピーをステージングサーバーにプルし、本番サーバーに適用する前にステージングサーバーに適用されるEF移行をテストします。 IMOこれは、EF移行を使用しているかどうかに関係なく、運用システムのスキーマ更新に不可欠です。


はい。CodeFirst Migrationsなどの自動化システムを使用して 本番 データベースを変更し ないの には十分な理由があります。 しかし、いつものように、ルールには例外があります。

  1. 言及された理由の1つは、アクセス許可です。これは、組織の変更管理ルールとセキュリティポリシーに直接関連しています。

  2. もう1つの理由は、移行ツール自体に対する信頼レベルです。 ツールにバグがないことを確認していますか? ツールが途中で失敗するとどうなりますか? 最新のバックアップと、必要に応じてロールバックするプロセスがあることを確信していますか?

  3. 変更スクリプトは、予期しないまたは非効率的なスクリプトを実行する場合があります。 生成されたSQLが一時テーブルにデータをコピーし、元のテーブルを削除し、誤って(または意図的に)列の表示順序を変更した場合に新しい列を追加するなどの目的で元の表を再作成した場合、または、テーブルの名前を変更したとき。 何百万ものレコードが関係している場合、これは深刻なパフォーマンスの問題を引き起こす可能性があります。

私の推薦:

実稼働スキーマをミラーリングするステージングデータベースがある場合、移行ツールを使用して、そのシステムに対して変更スクリプトを生成します。 通常、実行前にステージデータベースを新しい運用コピーから復元します。 次に、変更スクリプトを手動で調べて問題を確認します。 その後、ステージデータベースに対してスクリプトを実行し、スクリプトが適切に実行され、予想されるすべての変更が行われたことを確認します。 これで、スクリプトが本番環境で実行しても安全であり、予想される変更を実行できることが確認されました。 このプロセスは、上記の3つの問題すべてに対処します。


私はいくつかのプロジェクトの本番環境で使用しています。 一度コツをつかめば大丈夫だと思う。

開発中は自動移行をオンにできますが、最後にパッケージマネージャーコンソールからライブデータベースに直接接続し、移行を生成できます。 すべての変更に対して1回の移行が行われます。

ただし、常に update-database で常に -script オプションを使用し、自分でSQLを起動します。

また、web deployのupdate dbオプションを使用しないことをお勧めします。 そのようにすると、エラー時に既にどのくらいの移行が実行されたかを知る方法はありません。 私はそれで数回問題に遭遇しました。 したがって、SQLを取得して手動で起動するのが最善です。





ef-migrations