簡単に言えば、あなたがしようとしているのは、データベース スキーマのバージョンを変更して、物事が変化してもコードと一致するようにすることです。これを行う上で重要なのは、DB スキーマへの変更を追跡できることと、DB スキーマの現在の状態 (つまり、どのバージョンであるか) を追跡できることです。
スキーマへの変更を追跡する 1 つの方法は、スキーマへのすべての変更を手動でスクリプト化することです。これらの変更スクリプトは、基本的に、スキーマのバージョン間の「差分」です。これらの変更ファイルを生成する別の方法は、2 つのデータベース間、またはデータベースと作成スクリプト間の差分を生成できるプログラムを使用することです。理論的には、その作業コピーの現在のデータベースとその作業コピーの以前のデータベースから変更スクリプトを生成できる pre-commit フック スクリプトを開発できるはずですが、これは簡単な作業ではありません。
DB をバージョン管理したら、これらの変更を に適用する問題を解決する必要がありますUpdate。Versionこれを行うには、データベース (おそらく、Mercurial 変更セット ID にリンクするデータベース内のある種のテーブル) を見て、どのスクリプトを実行する必要があるかを判断できるポスト更新フックを開発する必要があります。 DBを最新に。
Mercurial では以前のバージョンへの更新が許可されているため、データベースに互換性を損なわない変更のみを行うか、(社会的または技術的な意味で) 運用作業コピーを以前のバージョンに更新することを単に許可しない必要があります。 . どのように処理するかに関係なく、実際の DB 更新を行うポスト更新フック スクリプトは、既に適用されている DB 変更スクリプトを適用しようとするのに十分なほどスマートである必要があります。
これをすべて機能させるには、解決すべき問題が数多くあり、多くのテストを行う必要があることは明らかです。これは決して事前に構築されたソリューションではありませんが、 DB を更新して、コードに合わせて更新します。幸運を！
Rails フレームワークを見てみましょう。データベースの移行を使用して、データベースを操作 (さらには作成) します。テストとの統合や、開発マシン間での統合にも優れています (チーム向け)。これは Ruby (多くの人が PHP よりも好ましいと考えている) であるため、切り替えない限り機能しませんが、アプリケーションにこれを実装する方法についていくつかのアイデアが得られるかもしれません。
http://guides.rubyonrails.org/migrations.html
移行は、データベースを構造化および整理された方法で変更するための便利な方法です。SQL のフラグメントを手動で編集することもできますが、その場合、他の開発者にそれらを実行する必要があることを伝える責任があります。また、次にデプロイするときに、運用マシンに対してどの変更を実行する必要があるかを追跡する必要があります。
Active Record はどのマイグレーションが既に実行されたかを追跡するので、ソースを更新して rake db:migrate を実行するだけです。Active Record は、どの移行を実行する必要があるかを判断します。また、データベースの構造に一致するように db/schema.rb ファイルを更新します。