php - DB スキーマの変更を追跡するメカニズム

Question

DB スキーマの変更を追跡および/または自動化するための最良の方法は何ですか? 私たちのチームはバージョン管理に Subversion を使用しており、この方法で一部のタスクを自動化できました (ステージングサーバーへのビルドのプッシュ、テスト済みコードの運用サーバーへのデプロイ) が、データベースの更新は手動で行っています。コードと DB の更新をさまざまなサーバーにプッシュするバックエンドとして Subversion を引き続き使用しながら、さまざまな環境のサーバー間で効率的に作業できるソリューションを見つけるか作成したいと考えています。

多くの一般的なソフトウェアパッケージには、DB のバージョンを検出して必要な変更を適用する自動更新スクリプトが含まれています。大規模な場合でも (複数のプロジェクトや複数の環境や言語にまたがって)、これを行うための最良の方法はありますか? もしそうなら、プロセスを簡素化する既存のコードはありますか、それとも独自のソリューションを展開するのが最善ですか? 誰かが以前に似たようなものを実装し、それを Subversion のコミット後のフックに統合したことがありますか? それとも、これは悪い考えですか?

複数のプラットフォームをサポートするソリューションが望ましいですが、作業の大部分が Linux/Apache/MySQL/PHP スタックをサポートする必要があります。

score 57 · Accepted Answer

Rails の世界では、マイグレーションの概念があります。これは、データベースへの変更がデータベース固有の SQL ではなく、Ruby で行われるスクリプトです。Ruby 移行コードは、現在のデータベースに固有の DDL に変換されます。これにより、データベースプラットフォームの切り替えが非常に簡単になります。

データベースに変更を加えるたびに、新しい移行を作成します。通常、移行には 2 つの方法があります。変更が適用される「上」の方法と、変更が元に戻される「下」の方法です。1 つのコマンドでデータベースが最新の状態になり、データベースを特定のバージョンのスキーマにするために使用することもできます。Rails では、マイグレーションはプロジェクトディレクトリ内の独自のディレクトリに保持され、他のプロジェクトコードと同様にバージョン管理にチェックインされます。

Rails の移行に関するこの Oracle ガイドでは、移行について十分に説明しています。

他の言語を使用している開発者は移行を検討し、独自の言語固有のバージョンを実装しています。Ruckusingは、Rails の移行をモデルにした PHP 移行システムです。それはあなたが探しているものかもしれません。

score 50 · Accepted Answer

bcword に似たものを使用して、データベーススキーマを 5 つの異なるインストール (運用、ステージング、およびいくつかの開発インストール) 間で同期させ、バージョン管理でバックアップします。これは非常にうまく機能します。少し詳しく説明します。

データベース構造を同期するために、1 つのスクリプト update.php と、1.sql、2.sql、3.sql などの番号が付けられた多数のファイルがあります。スクリプトは、1 つの追加テーブルを使用して、データベース。N.sql ファイルは手動で作成され、データベースのバージョン (N-1) からバージョン N に移行します。

それらを使用して、テーブルの追加、列の追加、古い列形式から新しい列形式へのデータの移行、列の削除、ユーザータイプなどの「マスター」データ行の挿入などを行うことができます。基本的には、適切なデータを使用して何でも実行できます。移行スクリプトを使用すると、データが失われることはありません。

更新スクリプトは次のように機能します。

データベースに接続します。

現在のデータベースのバックアップを作成します (問題が発生するため) [mysqldump]。

簿記テーブル (_meta と呼ばれる) が存在しない場合は作成します。

_meta テーブルから現在の VERSION を読み取ります。見つからない場合は 0 と仮定します。

VERSION よりも大きい番号が付けられたすべての .sql ファイルについて、それらを順番に実行します。

いずれかのファイルでエラーが発生した場合: バックアップにロールバックします

それ以外の場合は、簿記テーブルのバージョンを、実行された最新の .sql ファイルに更新します。

すべてがソース管理に入り、すべてのインストールには、1 回のスクリプト実行 (適切なデータベースパスワードを使用して update.php を呼び出すなど) で最新バージョンに更新するためのスクリプトがあります。データベース更新スクリプトを自動的に呼び出すスクリプトを介してステージング環境と運用環境を SVN 更新するため、必要なデータベース更新と共にコード更新が行われます。

同じスクリプトを使用して、データベース全体を最初から再作成することもできます。データベースを削除して再作成し、データベースを完全に再作成するスクリプトを実行するだけです。スクリプトを使用して、自動テスト用に空のデータベースを作成することもできます。

このシステムをセットアップするのに数時間しかかかりませんでした。概念的にはシンプルで、誰もがバージョン番号付けスキームを取得できます。変更を伝達したり手動で実行したりすることなく、データベース設計を前進させて進化させることができるという点で非常に貴重です。すべてのデータベースで。

ただし、phpMyAdmin からクエリを貼り付ける場合は注意してください。これらの生成されたクエリには通常、データベース名が含まれていますが、これはスクリプトを壊してしまうため、絶対に望ましくありません。CREATE TABLE のようなものmydb。newtable(...) システム上のデータベースが mydb と呼ばれていない場合、失敗します。mydb文字列を含む .sql ファイルを許可しない、コメント前の SVN フックを作成しました。

score 12 · Accepted Answer

私のチームは、すべてのデータベースの変更をスクリプト化し、それらのスクリプトをアプリケーションのリリースごとに SVN にコミットします。これにより、データを失うことなく、データベースの増分変更が可能になります。

あるリリースから次のリリースに移行するには、一連の変更スクリプトを実行するだけで、データベースは最新の状態になり、すべてのデータを取得できます。最も簡単な方法ではないかもしれませんが、確実に効果的です。

score 10 · Accepted Answer

あなたがまだ解決策を探しているなら：私たちはneXtepdesignerと呼ばれるツールを提案しています。これは、データベース全体をバージョン管理下に置くことができるデータベース開発環境です。すべての変更を追跡できるバージョン管理されたリポジトリで作業します。

アップデートをリリースする必要がある場合は、コンポーネントをコミットでき、製品は以前のバージョンからのSQLアップグレードスクリプトを自動的に生成します。もちろん、このSQLは任意の2つのバージョンから生成できます。

次に、多くのオプションがあります。これらのスクリプトを取得して、アプリコードとともにSVNに配置し、既存のメカニズムでデプロイできるようにすることができます。もう1つのオプションは、neXtepの配信メカニズムを使用することです。スクリプトは「配信パッケージ」（SQLスクリプト+ XML記述子）と呼ばれるものでエクスポートされ、インストーラーはこのパッケージを理解して、構造の一貫性と依存関係を確保しながらターゲットサーバーにデプロイできます。確認、インストール済みバージョンの登録など。

この製品はGPLであり、Eclipseに基づいているため、Linux、Mac、およびWindowsで動作します。現在、Oracle、MySQL、PostgreSQLもサポートしています（DB2のサポートは現在進行中です）。より詳細な情報が掲載されているwikiをご覧ください：http： //www.nextep-softwares.com/wiki

score 10 · Accepted Answer

ここでの問題は、開発者が独自のローカル変更をソース管理にスクリプト化して、チームと共有することを本当に簡単にすることです。私は長年この問題に直面してきましたが、データベースプロフェッショナル向けの Visual Studio の機能に触発されました。同じ機能を備えたオープンソースツールが必要な場合は、これを試してください: http://dbsourcetools.codeplex.com/ 楽しんでください - Nathan。

score 8 · Accepted Answer

Scott Ambler produces a great series of articles (and co-authored a book) on database refactoring, with the idea that you should essentially apply TDD principles and practices to maintaining your schema. You set up a series of structure and seed data unit tests for the database. Then, before you change anything, you modify/write tests to reflect that change.

We have been doing this for a while now and it seems to work. We wrote code to generate basic column name and datatype checks in a unit testing suite. We can rerun those tests anytime to verify that the database in the SVN checkout matches the live db the application is actually running.

As it turns out, developers also sometimes tweak their sandbox database and neglect to update the schema file in SVN. The code then depends on a db change that hasn't been checked in. That sort of bug can be maddeningly hard to pin down, but the test suite will pick it up right away. This is particularly nice if you have it built into a larger Continuous Integration plan.

score 7 · Accepted Answer

スキーマをファイルにダンプし、ソース管理に追加します。次に、単純な差分により、何が変更されたかがわかります。

score 6 · Accepted Answer

K. Scott Allen has a decent article or two on schema versioning, which uses the incremental update scripts/migrations concept referenced in other answers here; see http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.

score 5 · Accepted Answer

これは一種のローテクであり、より良い解決策があるかもしれませんが、データベースを作成するために実行できる SQL スクリプトにスキーマを保存することもできます。このスクリプトを生成するコマンドを実行できると思いますが、残念ながらそのコマンドはわかりません。

次に、スクリプトを、そのスクリプトで動作するコードと共にソース管理にコミットします。コードと共にスキーマを変更する必要がある場合は、変更されたスキーマを必要とするコードと共にスクリプトをチェックインできます。次に、スクリプトの差分は、スキーマ変更の差分を示します。

このスクリプトを使用すると、DBUnit や何らかのビルドスクリプトと統合できるため、既に自動化されているプロセスに適合するようです。

score 5 · Accepted Answer

C# を使用している場合は、非常に便利な ORM ツールである Subsonic をご覧ください。これは、スキームやデータを再作成するための SQL スクリプトも生成します。その後、これらのスクリプトをソース管理に入れることができます。

http://subsonicproject.com/

score 5 · Accepted Answer

私たちは非常にシンプルでありながら効果的なソリューションを使用しています。

新規インストールの場合、リポジトリにすべての DB スキーマを保持する metadata.sql ファイルがあり、ビルドプロセスでこのファイルを使用してデータベースを生成します。

アップデートについては、ハードコードされたソフトウェアにアップデートを追加します。問題が実際に問題になる前に問題を解決するのは好きではないので、ハードコーディングしておきます。この種のことは、これまでのところ問題であることが証明されていません。

したがって、私たちのソフトウェアには次のようなものがあります。

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

このコードは、データベースがバージョン 1 (自動的に作成されたテーブルに格納されている) であるかどうかをチェックし、バージョンが古い場合は、コマンドが実行されます。

リポジトリ内の metadata.sql を更新するには、このアップグレードをローカルで実行してから、完全なデータベースメタデータを抽出します。

頻繁に発生する唯一のことは、metadata.sql のコミットを忘れることですが、これは大きな問題ではありません。なぜなら、ビルドプロセスで簡単にテストでき、発生する可能性がある唯一のことは、新しいインストールを作成することだけだからです。古いデータベースであり、最初の使用時にアップグレードしました。

また、ダウングレードはサポートしていませんが、これは仕様によるものであり、アップデートで問題が発生した場合は、以前のバージョンを復元し、アップデートを修正してから再試行します。

score 5 · Accepted Answer

Visual Studio で次のデータベースプロジェクト構造をいくつかのプロジェクトに使用しましたが、うまく機能しています。

データベース

変更スクリプト

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

スクリプトを作成する

スプロケット

機能

ビュー

次に、ビルドシステムは、次の順序でスクリプトを実行することにより、データベースをあるバージョンから次のバージョンに更新します。

1.PreDeploy.sql

2.SchemaChanges.sql

Create Scripts フォルダの内容

2.DataChanges.sql

3.Permissions.sql

各開発者は、各ファイルの末尾にコードを追加することにより、特定のバグ/機能の変更をチェックインします。メジャーバージョンが完成し、ソース管理で分岐されると、Change Scripts フォルダー内の .sql ファイルの内容が削除されます。

score 4 · Accepted Answer

ビルドバージョンにちなんで名付けられたフォルダーを作成し、そこにアップグレードスクリプトとダウングレードスクリプトを配置します。たとえば、次のフォルダを作成できます：1.0.0、1.0.1、および1.0.2。それぞれに、バージョン間でデータベースをアップグレードまたはダウングレードできるスクリプトが含まれています。

クライアントまたは顧客からバージョン1.0.1の問題で電話があり、1.0.2を使用している場合でも、データベースを元のバージョンに戻すことは問題になりません。

データベースに、現在のバージョンのデータベースを配置する「スキーマ」というテーブルを作成します。そうすれば、データベースをアップグレードまたはダウングレードできるプログラムを簡単に作成できます。

Joeyが言ったように、Railsの世界にいる場合は、Migrationsを使用してください。:)

score 3 · Accepted Answer

Toad for MySQL には、2 つのデータベースを同期できるスキーマ比較という機能があります。これは、私がこれまでに使用した中で最高のツールです。

score 3 · Accepted Answer

db-deploy を試してください - 主に Java ツールですが、php でも動作します。

score 3 · Accepted Answer

「スクリプト」側には Ant (クロスプラットフォーム) を使用することをお勧めします (jdbc を介して任意のデータベースと実際に通信できるため)、ソースリポジトリには Subversion を使用することをお勧めします。Ant では、変更を加える前に、データベースをローカルファイルに「バックアップ」できます。

Antを介して既存のdbスキーマをファイルにバックアップします
Ant を介した Subversion リポジトリへのバージョン管理
Antを介して新しいSQLステートメントをdbに送信します

score 3 · Accepted Answer

Yiiがデータベースの移行を処理する方法が気に入っています。移行は、基本的にはを実装する PHP スクリプトCDbMigrationです。移行ロジックを含むメソッドをCDbMigration定義します。移行の反転をサポートするメソッドをup実装することもできます。downまたは、移行がトランザクションのコンテキストで行われることを確認するためにsafeUp使用safeDownできます。

Yii のコマンドラインツールyiicには、マイグレーションの作成と実行のサポートが含まれています。移行は、1 つずつまたはバッチで適用または元に戻すことができます。CDbMigration移行を作成すると、ユーザーが指定したタイムスタンプと移行名に基づいて一意の名前が付けられたを実装する PHP クラスのコードが作成されます。以前にデータベースに適用されたすべての移行は、移行テーブルに格納されます。

詳細については、マニュアルのデータベース移行の記事を参照してください。

score 3 · Accepted Answer

私の現在の PHP プロジェクトでは、rails migrations のアイデアを使用しており、"migration_XX.sql" というタイトルのファイルを保持する migrations ディレクトリがあります。ここで、XX は移行の番号です。現在、これらのファイルは更新時に手動で作成されていますが、作成されたファイルは簡単に変更できます。

次に、「Migration_watcher」というスクリプトがあります。これは現在、プレアルファ版であるため、ページが読み込まれるたびに実行され、XX が現在の移行バージョンよりも大きい新しい migration_XX.sql ファイルがあるかどうかを確認します。もしそうなら、それはデータベースに対して最大数まですべての migration_XX.sql ファイルを実行し、ほら! スキーマの変更は自動化されています。

システムを元に戻す機能が必要な場合は、多くの微調整が必要になりますが、それは簡単で、これまでかなり小規模なチームにとって非常にうまく機能しています.

score 2 · Accepted Answer

私見の移行には大きな問題があります。

あるバージョンから別のバージョンへのアップグレードは正常に機能しますが、何百ものテーブルと長い変更履歴がある場合 (私たちのように)、特定のバージョンの新規インストールを行うと、永遠に時間がかかる場合があります。

ベースラインから現在のバージョン (何百もの顧客データベースの場合) までのデルタの全履歴を実行するには、非常に長い時間がかかる場合があります。

score 0 · Accepted Answer

データベーススキーマを比較するコマンドラインmysql-diffツールがあります。スキーマはライブデータベースまたはディスク上のSQLスクリプトです。ほとんどのスキーマ移行タスクに適しています。

php - DB スキーマの変更を追跡するメカニズム

20 に答える 20

Related

Reference