私はこのトピックについて多くのことを考え、読みました。これは、構成制御と変更管理戦略の広範なトピックです。このトピックにはCMMIのドメインがあります。CMMI 3-5の認定を取得している企業でも、データベースをバージョン管理しない場合があります。
この質問は、制約に従うことを念頭に置いて回答する必要があります。
- キーパーがいて、すべてのDDLがこのキーパーによって実行されます。
- 他の人々はDDLステートメントを実行する能力を持っています。
- どのような変更が行われたかを記録するだけでよく、大きな違いを比較する必要はありません。
- データベース設計は外部ツールを介して行われ、その後データベースに公開されます。この外部ツールは、ソース管理のDDLスクリプトでもかまいません。しかし重要なのは、これをソース管理してからデータベースに公開することです。
- 瞬間的な変化を知る必要はありませんが、時々：すなわち、毎時、毎日。
- 定義済みのサーバー構造（開発、テスト、実稼働）があります。そして、優れたテスト戦略。
回答1
- 1、4、6がtrueの場合、外部ソース管理を使用できます。例えば
- Embercaderoにはデータベース変更管理ツールがあります（http://www.embarcadero.com/products/db-change-manager-xe）。これは、データベース（Oracle）をリバースエンジニアリングし、ソース管理に入れることができます。その後、任意の数の開発者であるdbaがこのスキーマにアクセスして変更できます。
- Oracle SQL Designerはこのアプローチに似ています。
- ソーススクリプト（svn、mercurialなど）にテーブルスクリプトを作成し、同じことを維持します。
- http://www.liquibase.orgは上記の自動化されたアプローチです。
- DAL（データアクセスレイヤー）、DDL（テーブル作成）ステートメントを生成するコードジェネレーターを作成しました。ソース管理を行い、そこで管理しました。liquibaseのような専用ソリューションの方がうまくいくと思います。
このアプローチは、6がある場合にうまく機能します。ソース管理にDDLステートメント（コードでもあります）を配置し、それを保守します。誰も十分に考慮せずにテストサーバーと運用サーバーを変更することはありません。
短所は、何らかの理由で運用サーバーまたはテストサーバーに変更を加えた場合、簡単なバグ修正、主キーの変更などです。その変更を開発サーバーにもロールする必要があります。実際には開発サーバーがあなたの地上の真実だからです。他の方法ではありません。
これは非常に開発者指向のアプローチです。しかし、新しいモジュールを最初に開発するときは、かなりうまく機能します。
回答2-1
と6が真の場合：
回答1への同様のアプローチは、開発サーバーの保守です。誰もがそれを使用して変更します。更新する時が来たときより。データベース比較ツールを使用します。これらをスクリプトとして取得し、ソース管理下に置きます。
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
回答1と回答2の違いは、回答1では、データベース全体のDDLステートメントを収集して保存することです。回答2では、すべてのバージョンの変更を保存する必要があります。
- 開始
- V1
- V2
- V3
- ...
列をテーブルに配置し、後で削除することにした場合。スクリプトはこれをanswer2に表示しますが、answer1には最後のバージョンのみが表示されます。そして、違いを確認するにはV2とV1を比較する必要があります。個人的には、Start 1とV3、V1、V3を簡単に比較できるので、回答1の方が好きです。answer2では、すべての変更を探す必要があります。また、回答2では、ソース管理のスクリプトはビッグバンで複雑なスクリプトになる傾向があります。情報を見つけるのは難しい。
回答3
3が真の場合。この状況では、制約6がないことに注意してください。つまり、開発、テスト、製品サーバーはありません。実稼働サーバーのみ。DDLトリガーを使用して、行われた変更を記録できます。これは主に、人々がDDL助成金を乱用するのを思いとどまらせるために使用されます。問題が発生した場合、責任を負うことができます。これが機能するためには、すべての人が自分のユーザーアカウントに接続し、アプリケーションアカウントにDDLの許可を与えないでください。すべての開発者がアプリケーションアカウントを知っており、使用できるためです。
回答4
3と5がある場合、この状況では制約6がないことに注意してください。つまり、開発、テスト、製品サーバーがありません。実稼働サーバーのみ。変更を保存するトリガーの代わりに。外部ツールを使用して変更を見つけ、ソース管理にDDLスクリプトを保存します。
これらのツールが変更を行った人を記録する機能を備えている場合、便利です。このソリューションでは、間隔を空けて行われる余分なDDLを失うことに注意してください。