最新のデータで開発していることを確認するために、テスト サーバーのデータベースを運用サーバーのデータベースから毎晩更新したいと考えています。ただし、現在開発環境で作業している fn や sp などは、バックアップ プロセスによって上書きされないようにしたいと考えています。私たちが考えていたのは、開発者が選択したオブジェクトを保存するプレバックアップ プログラムと、バックアップ プロセスの完了後にオブジェクトを追加するポストバックアップ プログラムを用意することでした。
このような状況で、他の開発者は何をしているのか気になりました。これを行うための既存のツールがあり、毎日自動的に実行でき、オブジェクトを上書きしないように設定できます (システム管理者が毎日実行する必要はありません)。
データベース内のすべてのオブジェクト (テーブル、ビュー、トリガー、ストアド プロシージャなど) はすべてコードで維持されます。データベース内にあると予想される場合は、実行可能なコード内の DDL に含まれている必要があります。実際のスキーマの変更はバージョン管理されているため、これがスキーマ バージョン「n」であることを示すテーブルがデータベースにあり、これが (更新コードによると) 現在のバージョンでない場合は、必要な変更を行います。
トリガーとビューを分離するように努めています。SP と FN をあまり使用しないでください。現在のスキーマ バージョンで有効なコードを削除して再作成します。したがって、オブジェクト間に依存関係がある場合、削除と作成の両方で順序付けの問題が発生しますが、テーブル以外のものを削除して再作成することは「安全」である必要があります。一般的に、これの良い点は、スキーマを新しいものから最新のものに自信を持って持ち込むことができ、スキーマのすべてのインスタンスが一貫しているという確信を持つことができることです。
あなたのケースに拡張すると、現在の定義に従ってすべてのデータベース オブジェクトを再作成するコードを含むスキーマ更新コードを実行できる場合、問題は実質的に解消されるはずです...バックアップ、復元、スキーマ保守ロジックの実行。これには、開発サーバーにスキーマ (テーブル) の変更を導入しても、同じ更新ロジックを維持できるというさらなる利点があります。
これが完全に一般的な解決策ではないことはわかっています。そして、おそらく開発者ごとにデータベースの方がうまく機能することに注意する価値があります（私は昔ながらのプログラマーなので、すべての問題をコードベースのソリューションで解決できると考えています（-:）が、一般的なアプローチとしては、多くの問題に対処するための一貫したメカニズムです。