私は以下に関する情報を探しています：
開発DBのスキーマを本番DBに更新するための、またはより簡潔にDBスキーマの変更を一般的に行うためのベストプラクティスは何ですか。
本番データベースは、2つの異なるASP.NETWebサイトのバックエンドです。
私たちのスキーマ変更プロセスはかなり堅牢であり、各「移行」は実際にはスキーマ変更を含む.csファイルです。次に、ADO.NETを使用して、データベースに対してスキーマの変更を適用します。
私の質問は、データベースの接続性についてです。
dbにアクセスしている2つのWebサイトを停止する必要があります。私はそうすべきだと思います。DBをシングルユーザーモードにする必要があります。私はそうすべきであるように見えますが、私はそれについて完全に自信を持っているわけではありません。
何が欠けている可能性がありますか？DBスキーマの変更に関して、以前に手にしたことは何ですか。
更新によって列名、ストアド プロシージャ パラメーターなどが変更された場合は、スキーマの更新を行う前にアプリを常にオフラインにします。
更新がデータの通常の処理に影響を与えないもののみである場合は、「ホット」にできる可能性があります。このカテゴリは、インデックス、テーブルなどを追加する場合です。
スキーマの更新の処理中に誰かがアプリを使用している場合、データの一貫性が損なわれる状況に陥る可能性が非常に高くなります。
この更新に対応する Web アプリケーション ファイルの更新が必要な場合は、更新を実行する前にサイトをオフラインにしてください。誰がページを閲覧しているかわからず、[送信のみ] をクリックしてエラーを表示しようとしています...
通常、この種のメンテナンスはオフピーク時に行われます。サイトがいつ、どのくらいの間ダウンするかについて、事前にユーザーに通知する必要があります。
また、Redgate の SQL Compare などのツールを使用して、db 更新のスクリプトを作成しています。これは、実際のプッシュの前に本番データから更新されたステージング サーバーで実施され、予期せぬ事態が発生せず、非常に迅速に実行できるようにします。
シングル ユーザー モードに関しては、通常、これを使用して、データベースへのアクセスを単一の管理スタジオ インスタンスに制限します。これは、展開の一部として通常行うことではありません。
.cs/ado.net ルートを使用してスキーマを変更することは考慮していません。私たちがしているのは、「デルタ」.SQL ファイル (変更を行うための SQL) を作成することです。これらは変更を行うために既知のリビジョンのスキーマに対して実行され、.SQL の実行は展開の一部です。
できる限り、列やインデックスなどの存在などの特定のものについてスキーマをチェックすることにより、これらを複数回実行しても安全になるようにします。そのようにして、「偶然に」複数回実行される可能性があります。
展開するときは、1 日/1 週間の特定の時間帯を設定し、ユーザー/顧客に警告し、Web サイトをシャットダウンするなどします。リリース前の最後の数日間、開発サーバーとステージング サーバーでほぼ毎日「練習」展開が行われるため、最終的な展開の信頼性が得られます。は高い。
スキーマの変更を SQL に保持すると、変更する「マスター」スキーマ SQL のように見えるため、追跡しやすくなります。デバッグも少なくなります！
それらは、残りのコードとともに TFS でも管理されます。
理想的な状況ですが、常に実現できるわけではありません: Web サイトの V<old> バージョンと互換性のあるスキーマ変更を行います。次に、V<new> を Web サーバーにリリースします。すべての Web サーバーが V<new> に移行したら、クリーンアップ (欠落している値の入力など) を実行してから、適切な null 可能性の変更を行うことができます。