SQLテーブルの変更をどのようにバージョン管理/追跡しますか？

全員がローカルテーブルと開発テーブルを変更する開発者のチームで作業する場合、どのようにしてすべての変更を同期しますか？誰もがSQLの変更を保持する中央ログファイルですか？テーブルの変更ステートメント、ローカルデータベースを最新バージョンにするために開発者が実行できる個々の.sqlファイルを追跡するWikiページですか？私はこれらのソリューションのいくつかを使用しましたが、うまく機能する優れた堅実なソリューションを一緒に得るために努力していますので、あなたのアイデアに感謝します。

コードベースのデータベース移行ツールを使用し、ソース管理に移行コードを保持します。

タイムスタンプをバージョン番号として使用することにより、任意の数の開発者が自由に移行を追加でき、データベースのコピーに対して移行ツールを自信を持って実行できます。

以前はバージョン管理下でSQLスクリプトを使用していましたが、コードベースのアプローチははるかに簡単で、すべてが1つの論理的な「スポット」にあり、必要なすべてのスクリプトを1つのコマンドで実行できるためです。

私は自分でやっていませんが、一部の開発者は、実行時にテスト目的でデータベーステーブルを再作成し、運用目的で空のデータベースを構築できるソース管理下のSQLスクリプトのコレクションを維持しています。

フィールドまたはテーブルを追加または削除する必要がある場合、またはデータ変換を実行する必要がある場合、同じ手法を使用して顧客サイトでデータベースをバージョン管理できます。

バージョン管理および継続的インテグレーションの下でスクリプトをビルドして検証する

私のために働いた1つのアプローチは、各開発者が自分の好きなことをできる独自のスキーマで作業することでした。それらのスキーマは破壊可能であり、すべての開発者が貢献したバージョン管理された一連のスクリプトから取得したテストデータが格納されていました。

夜間の継続的インテグレーションビルドでは、すべてのスクリプトの最新バージョンを使用し、それらから一貫したテストデータベースを構築しようとしました。その後、アプリケーションに対して一連の統合と機能テストを実行し、現在のスキーマが現在のリリース候補と一致しているかどうかを検証しました。

この道を始める前に、かなり堅実なデータベース設計が行われ、DBAは常に非正規化やその他の恐怖で開発者が怒らないように注意を払っていました。

ここでは、スクリプトの変更がすぐに明らかになるため、バージョン管理が非常に役立ちました。また、データベースVERSIONテーブルを使用して、データベースの全体的な状態を特定しました。これは単純な整数シーケンスであり、特定のアプリケーションにリンクされていません。

全体として、それはうまく機能し、開発者は他の人に影響を与えることなく常に自分のスキーマをロールバックできるため、永続層を変更することを恐れなくなりました。

MSショップにいる場合、Visual Studio 2010には優れたデータベースバージョン管理ツールがあり、2つのデータベースの違いに基づいて変更/展開スクリプトを生成することもできます。

スキーマや他のSQLスクリプトをバージョン管理下に置くことに加えて、もう1つの便利なプラクティスは、実際のDBに「スキーマバージョン」テーブルを維持することです。

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

Doctrineには素晴らしい移行ツールがあります：http : //www.doctrine-project.org/documentation/manual/1_2/en/migrations、最良の部分はそれらが自動生成されるか、手作業で簡単にコーディングできることです。

私が使用するアプローチは、パラメーターに1つのテーブルを提供することです。このテーブルには、データベースが存在するバージョンに対して名前と値のペアが1つあります。これにより、2つの利点が得られます。データベースのみの修正がアプリケーションを通じて適用されたことを確認する方法があり、その値をSQLスクリプトに使用できます。

SQLスクリプトは、新しいテーブルを作成し、列を変更し、以前のバージョンからスクリプトをプロモートするためにデータベースで必要な作業を行います。理想的にはロールバックスクリプトもありますが、ほとんどの場合はそうではありません。

ところで、このアプローチ全体は、ロールバックスクリプトを備えたRuby on Railsの一部として自動化されています。私はその考えが好きですが、すべてのフレームワークがそうするわけではありません。Ruby on Railsを使用していないときは、上記のアプローチを使用します。