1

これは、すべての Web アプリケーションで繰り返し発生する問題のようです。あなたはバックエンド コードを改善しており、そのためにデータベース内のテーブルを変更する必要があります。開発システムで手動で行うのは問題ありませんが、更新されたコードを運用サーバーにデプロイするときは、データベース テーブルも自動的に変更する必要があります。

これらの状況に対処するためのさまざまな方法を見てきましたが、すべてに利点と独自の問題があります。大まかに、次の 2 つの可能性にたどり着きました。

  1. 専用の更新スクリプト。更新を手動で開始する必要があります。すべてのテーブルの変更を事前定義された順序で行う必要があります (厳格なリリース計画、データベースの簡単な迅速な修正はありません)。通常、別の更新プロセスと、バージョン番号を記録および管理する何らかの方法を維持する必要があります。利点は、実行中のコードに影響を与えないことです。

  2. 実行時にテーブル プロパティをチェックし、必要に応じて変更します。手動の操作は不要で、テーブルの変更は任意の順序で発生する可能性があります (したがって、データベースの迅速な修正は簡単にデプロイできます)。もう 1 つの利点は、通常、コードの保守がはるかに簡単になることです。明らかな問題は、テーブルのプロパティを必要以上にチェックする必要があることです。

アプリケーションの更新時にデータベース テーブルを変更する他の一般的な可能性または方法はありますか?

4

1 に答える 1

2

私が見た中で最も効果的だったものを共有します。最初のオプションを拡張しているだけです。

本番環境でスキーマを更新するときに通常見た手順は次のとおりです。

  1. フロントエンド アプリケーションを停止します。これにより、スキーマの更新中にデータが書き込まれるのを防ぎます。リレーションシップが台無しになったり、テーブルが突然アプリケーションと同期しなくなったりして、書き込みが失敗することは望ましくありません。

  2. 接続を確立できないように、データベースを切断する可能性があります。場合によっては、自分の知らないデータベースを使用しているコードが存在することもあります!

  3. 最初のオプションで説明したように、スクリプトを実行します。それには間違いなく慎重な計画が必要です。変更を適用するには、事前に定義された順序が必要であることは間違いありません。また、スキーマの更新用とデータの更新用の 2 セットのスクリプトが必要になることがよくあります。たとえば、null 値を許容しないフィールドを追加する場合は、最初に null 値を許容するフィールドを追加してから、スクリプトを実行してデフォルト値を設定します。

  4. ロールバック スクリプトを用意します。必要と思われるすべての変更を行い (開発ではすべてうまく機能したため)、アプリケーションをオンラインに戻す前にアプリケーションが機能しないことに気付く可能性があるため、これは非常に重要です。出口戦略を立てるのは良いことです。そうすれば、「アプリケーションが壊れて、何時間もオフラインになっていて、どうしたらいいの?!」という恐ろしい状況に陥ることはありません。

  5. （4）が本当にうまくいかない場合に備えて、バックアップの準備ができていることを確認してください。

  6. アプリケーションの更新とデータベースの更新を調整します。通常、最初にデータベースの更新を行い、次に新しいコードをロールアウトします。

  7. (オプション) 多くの企業は、テストのために部分的な展開を行っています。私はこれを行ったことはありませんが、5 つのアプリケーション サーバーと 5 つのデータベース サーバーがある場合は、最初に 1 つのアプリケーション/1 つのデータベース サーバーにロールアウトして、それがどうなるかを確認できます。その後、問題がなければ、残りの生産マシンを続行します。

自分に最適なものを見つけるには、間違いなく時間がかかります。多くの本番データベースの更新を行った経験からすると、特効薬はありません。最も重要なことは、時間をかけ、変更を追跡する際に規律を守ることです (あなたが言及したようなバージョン管理)。

于 2013-01-22T17:29:11.460 に答える