データベース アーキテクト、開発者、およびコンサルタントとして、答えられる多くの質問があります。一つ、最近聞かれてまだ上手く答えられないのですが…
「データベースの変更を文書化し、整理し、単一開発者環境または複数開発者環境で効果的に展開できるようにするための最良の方法または手法の 1 つまたはいくつかは何ですか?」
これには、ストアド プロシージャやその他のオブジェクト スクリプトが含まれる場合がありますが、特にスキーマ (ドキュメントから新しい物理的な更新スクリプト、ロールアウト、そして完全な循環まで) が含まれます。これを実現するアプリケーションがありますが、スキーマ フックとオーバーヘッドが必要です。サードパーティの追加の関与なしに使用される手法について知りたいです。
データベースに列/テーブルを追加する限り、これらの変更を事前にSQLファイルにスクリプト化することで簡単な作業になります. あなたはそれらを実行するだけです。多分あなたはそれらを実行するための何らかの命令を持っています。
良い解決策は、テーブルごとに 1 つのファイルを作成することです。これにより、このテーブルに属するすべての変更が、テーブルで作業しているすべての人に表示されます (クラスで作業するようなものです)。同じことがストアド プロシージャまたはビューにも当てはまります。
より困難なタスク (したがって、おそらくツールが適している) は、後退することです。テーブル/列を追加しただけであれば、これは大きな問題ではないでしょう。ただし、更新時に列を削除した場合、更新を元に戻す必要がある場合、データはもう存在しません。このデータはバックアップから取得する必要があります。ただし、いくつかのテーブルよりも多くのテーブルがある場合、これは大きな作業になる可能性があることに注意してください。通常の場合、更新を非常に迅速に元に戻す必要があります。
バックアップを復元できれば、現時点では問題ありません。ただし、月曜日に更新すると、クライアントは水曜日まで動作し、一部のデータが欠落していることがわかります (テーブルから削除したばかりです)。古いデータベースを復元することはできません。
私は、スキーマの変更が「モデル化」され（たとえば、xmlごとに）、更新中にプロセッサ（たとえば、ac＃プログラム）が必要なすべての「sql " そして例えば、データを "dropDatabase" に移動します。データはそこに置くことができ、何らかの理由でドロップされたデータの一部を復元する必要がある場合は、プロセッサでそれを行うことができます. しばらくの間 (数年)、このアプローチはそれほど悪くないと思います。それ以外の場合、開発者はテーブルまたは列が本当に必要かどうかわからないため、「古い」テーブルに触れないからです。このアプローチを使用すると、何かを落としてもあまりリスクがありません!
私がすることは：
秘訣は、たとえば列を追加して再作成するためにデータベースを停止できない場合、ALTER TABLE とスクリプトの変更という2 つの変更を行う必要があるということです。もう少し手間がかかりますが、長期的には勝っています。