職場では、OracleとC#/ASP.netを使用して顧客のウェブサイトを管理していますが、このサイトは非常に大規模なので、データベースはとても大きい。
私たちはバージョン管理に Perforce を使用しており、データベースが変更されるたびに FogBugz ケースに作成または置換スクリプトを追加しています。これはこれまでは問題ありませんでした。現在、5 人の開発者がそれぞれ別の Perforce ブランチでシステムの 5 つの拡張に取り組んでいるからです。残念ながら、データベースのサイズの関係で重複したデータベースを取得できないため、全員が同じデータベースで作業しています。これは明らかに問題の原因です。わずか 10 分前に、ブランチのストアド プロシージャの変更が Pre-Production サーバーに伝播し、テスターに多数のクラッシュを引き起こすという問題がありました。理想的には、FogBugz を通じて手動で追跡することなく、これらの変更を追跡する方法が必要です。
私の質問は、皆さんはこの状況をどのように処理しますか? Oracle データベースでバージョン管理、または少なくとも変更の追跡を処理するための優れた方法が、今ではあるはずです。
答え1
11gR2 では、データベースのアップグレードが実行可能な場合のコードのエディション化の概念が導入されました。
データ スキーマはコード スキーマと同じですか? それらを分離することは良い考えです。そうすれば、データベース テーブルのセットは同じでも、コード スキーマのセットは異なるものになります。すると、1 つのプロジェクトで 1 つのコード スキーマを使用し、別のプロジェクトで別のスキーマを使用することができます。
単一のデータ セットに縛られている限り、制限があります。あるプロジェクトでは 1 つの文字の値が想定されているのに、別のプロジェクトではそれを 2 文字に拡張する場合、問題が発生する可能性があります。