Web アプリケーションがリリースされたときに DB で実行する必要がある一連の変更スクリプトを維持します。多くの時間を無駄にし、これらを最新の状態に維持するのに苦労していますが、DBA はライブ システムのストアド プロシージャとスキーマを (当然のことながら) 調整して、システムのパフォーマンスを維持することを好みます。
パッチを現在のスキーマとストアド プロシージャに合わせてリベースしなければならないことがよくありますが、どの変更が競合する可能性があるかを検出し、DBA のどの変更が上書きされている可能性があるかを判断することは非常に困難です。
他の人は、保留中の変更に対してライブ DB の変更の必要性をどのように管理していますか?
このプロセスをよりスムーズにするために、どのようなプロセスを導入できますか?
スキーマを保存、管理し、変更セットを適用する最良の方法は何ですか?
前もって感謝します。
DBA は、prod のみで proc を調整するべきではありません。また、ソース管理を使用し、他の環境に変更を加えて、変更を行っている他の人がそれらを認識できるようにする必要があります。
DB スキーマ スクリプト ベースにすべての DDL 変更を加え、ソース コード管理に保存します。特にDBAが行う変更-ベーススキーマとストアドプロシージャをソースコード管理にチェックインする前に、データベース開発者とDBAが検査することをお勧めします(HLGEMにそれを言ってください)。本番環境への移行は、アプリケーションの前にスクリプト化して承認する必要があります (つまり、DBA が変更が必要なものを見つけた場合、DBA に欠陥を開いてそのプロセスを介して処理してもらいます)。
そのようなすべての DDL 変更をロックして、開発者から遠ざけます。Java と C# を書いている頭のいい人は、設計の目標とデータベース側のニーズを最もよく達成する方法について、チームのデータベース「スペシャリスト」と連絡を取り合う必要があります。
本番環境の微調整は、状況に大きく依存するケースに限定してください。たとえば、多くの IT ショップには、アプリが提供するデータベース展開スクリプトに基づいて物理ストレージのセットアップを定義する DBA がいますが、通常は問題ありません。セットアップと基本的な調整に関する推奨事項のトップ 10 リストと共に、経験の浅いユーザーを支援するアプリのウィザードは大いに役立ちます。