私は新しい Web アプリの展開システムを開発中ですが、データベースの移行を管理するプロセスの最適なポイントはどこにあるのか疑問に思っています (移行をどのように行うかという問題は、まったく別の問題です)。
次の 2 つの方法があるようです。
これらのアプローチに関する提案/洞察/経験はありますか? 他の提案はありますか？
#1 がより魅力的である理由がわかります。これにより、DB がいつ更新されるかを完全に制御できます。しかし、私は #2 がとても気に入っています。なぜなら、デプロイ間をすばやく繰り返すことができ、手動プロセスを削減できるからです。#2 を開発マシンで使用して、イテレーションをさらに高速化することもできます。うーん、両方あって良かったかな…と思い始めました。
約 100 のクライアントを持つ営業システムがあり、アプリケーションの起動時にデータベースを更新しています (確かに、これはデスクトップ アプリケーションです)。私はこのアプローチが気に入っています。バージョン xyz にのみ更新されますか?)。
しかし、サーバー側では、私はあなたの #1 オプションを好みます: 仮想マシン上に (元のデータベースのコピーに基づいて) SQL クエリ ファイルを作成し、このクエリを実サーバーに対して実行します。
だから私見：
だから私もこの問題に興味があり、いくつかの（半分の）フレームワークをRikMigrationsとして見つけました。いくつかのグーグル検索の後、DB のバージョン管理/移行フレームワークに関する適切な出発点があります: .NET Database Migration Tool Roundup。必ずしもドキュメントではありませんが、チームのブログは興味深いものになる可能性があります。
はるかに柔軟に見えるので、オプション＃1の方が好きです。アプリの起動ごとに実際に移行を実行する代わりに、データベース スキーマ (バージョン番号?) がコードと一致することを確認し、一致しない場合は、データベース スキーマの不一致に関する警告またはエラーをスローすると思います。
I'd prefer option #1 for a number of reasons. First, integration tests usually require your DB schema to be up-to-date, and launching a web-site to upgrade the schema will be a huge timewaster. Second, you cannot change database schema while your site is running (say, add a couple of indexes to speed things up).
As for production side of things, upgrading your database in transaction MSI-style installation is much better than attempting to upgrade at each app startup since you can potentially end up with desynchronized database-application versions.
And if you're looking for the migration framework, take a look at Wizardby.
アプリケーションを顧客のマシンで実行する必要がある場合は、起動時に移行することで、多くのサポート コールを防ぐことができます - ユーザーの介入なしでシームレスな移行を実行できると仮定します (通常、データベースを変更する権限を持って Web アプリを実行していないことを願っています)。 ）。
アプリケーションが常に制御下で実行されている場合、自動移行はそれほど問題ではありませんが、特にダウンタイムと手動の展開手順を最小限に抑えたい場合は、優れた機能になる可能性があります。