7

データベーススキーマと変更のバージョン管理を開始する必要があることに気付いたところに到達しました。その結果、そのトピックに関するSOの既存の投稿を読みましたが、どのように進めるかがわかりません。

私は基本的に一人の会社であり、少し前まではコードにバージョン管理を使用していませんでした。私はWindows環境で、Aptana（IDE）とSVN（Tortoiseを使用）を使用しています。私はPHP/mysqlプロジェクトに取り組んでいます。

データベーススキーマをバージョン管理するための効率的で十分な（やり過ぎのない）方法は何ですか？

私はいくつかのプロジェクトでフリーランサーを1人か2人持っていますが、多くの分岐やマージが行われることは期待していません。したがって、基本的には、コードリビジョンへの同時スキーマを追跡したいと思います。

[編集]一時的な解決策：今のところ、タグをコミットするときはいつでも、スキーマダンプと必要な初期データを含む1つを作成することにしました（安定バージョン）。現段階ではそれで十分なようです。[/編集]

[edit2]さらに、increments.sqlという3番目のファイルも使用しています。ここでは、変更履歴を1つのファイルで簡単に追跡できるように、すべての変更を日付などで配置しています。時々、変更を他の2つのファイルに統合し、increments.sql[/edit]を空にします。

4

11 に答える 11

7

中小企業向けの簡単な方法：データベースをSQLにダンプし、リポジトリに追加します。その後、何かを変更するたびに、ダンプファイルに変更を追加します。

その後、diffを使用してバージョン間の変更を確認できます。もちろん、変更を説明するコメントもあります。これにより、MySQLのアップグレードの影響をほとんど受けなくなります。

これに私が見た1つの欠点は、SQLをダンプファイルに手動で追加することを忘れないようにする必要があることです。常に覚えるように自分を訓練することはできますが、他の人と一緒に作業する場合は注意が必要です。更新が欠落していると、後で苦痛になる可能性があります。

これは、Subversionに送信するときにそれを行うための複雑なスクリプトを作成することで軽減できますが、1人のショーでは少し大変です。

編集：この回答から過ぎ去った年に、私は小さなチームのためにMySQLのバージョニングスキームを実装しなければなりませんでした。コメントで言及されているように、各変更を手動で追加するのは面倒な解決策と見なされていたため、データベースをダンプして、そのファイルをバージョン管理に追加しました。

私たちが見つけたのは、テストデータが最終的にダンプに入れられ、何が変更されたかを把握するのが非常に困難になっていることでした。これはスキーマのみをダンプすることで解決できましたが、アプリケーションが機能するためにデータベース内の特定のデータに依存していたため、プロジェクトではこれは不可能でした。最終的に、データベースダンプに手動で変更を追加することに戻りました。

これは最も単純なソリューションであるだけでなく、MySQLの一部のバージョンでエクスポート/インポートに関して発生する特定の問題も解決しました。通常、開発データベースをダンプし、テストデータ、ログエントリなどを削除し、該当する場合は特定の名前を削除/変更してから、本番データベースを作成できるようにする必要があります。手動で変更を追加することで、最終的に本番環境に到達するものを少しずつ正確に制御できるため、最終的にはすべての準備が整い、本番環境への移行が可能な限り簡単になりました。

于 2009-04-16T11:32:11.207 に答える
2

これを行うことによって生成されたファイルのバージョン管理はどうですか？

mysqldump --no-data database > database.sql
于 2009-04-16T11:34:18.750 に答える
2

私が働いている場所では、アップグレードのために実行する必要のあるSQLを含むアプリの新しいバージョンごとにインストールスクリプトがあります。これは、メンテナンスリリース用にいくつかの分岐がある6人の開発者にとって十分に機能します。アップグレードするデータベースに適用するパッチの作成を処理する自動パッチhttp://autopatch.sourceforge.net/への移行を検討しています。自動パッチで分岐を処理する際に小さな問題が発生する可能性があるようですが、それが問題になるとは思えません。

于 2009-04-16T11:40:59.220 に答える
2

私は推測します、このようなバッチファイルは仕事をするはずです（タフにしようとしませんでした）...

mysqldump --no-data -ufoo -pbar dbname > path/to/app/schema.sql
svn commit path/to/app/schema.sql

スキーマを変更した後にバッチファイルを実行するか、cron /スケジューラに実行させます（ただし、わかりません...内容が同じであっても、タイムスタンプだけが変更された場合は、コミットが機能すると思います。しないでください。それが問題になるかどうかを知ってください。）

于 2009-04-16T12:15:37.683 に答える
2

主なアイデアは、プロジェクトのベースパスにこの構造のフォルダーを作成することです。

/__DB
—-/changesets
——–/1123
—-/data
—-/tables

これで、すべてが機能するのは、3つのフォルダーがあることです 。テーブル テーブル作成クエリを保持します。「table_name.sql」という名前を使用することをお勧めします。

データ テーブル挿入データクエリを保持します。同じ名前の「table_name.sql」を使用することをお勧めします。注：すべてのテーブルにデータファイルが必要なわけではありません。プロジェクトのインストール時にこの初期データが必要なテーブルのみを追加します。

チェンジセット これは、操作するメインフォルダーです。これは、初期構造に加えられた変更セットを保持します。これは、実際にはチェンジセットのあるフォルダーを保持します。たとえば、リビジョン1123で行われた変更（番号はコードソース管理からのもの）を含むフォルダー1123を追加し、1つ以上のSQLファイルを含めることができます。

xx_tablename.sqlという名前のテーブルにグループ化して追加するのが好きです。xxは、特定の順序で変更を実行する必要がある場合があるため、実行する必要のある順序を示す番号です。

注： テーブルを変更するときは、それらの変更をテーブルファイルとデータファイルにも追加します。これらは、新規インストールを実行するために使用されるファイルであるためです。

これが主なアイデアです。

詳細については、このブログ投稿を確認してください

于 2009-04-16T12:36:45.263 に答える
1

私たちの会社では、次のように行いました。

すべてのテーブル/データベースオブジェクトを、のように独自のファイルに配置しますtbl_Foo.sql。ファイルには、で区切られたいくつかの「パーツ」が含まれています

-- part: create

ここで、createは特定のパーツの単なる説明的なIDであり、ファイルは次のようになります。

-- part: create
IF not exists ...
CREATE TABLE tbl_Foo ...
-- part: addtimestamp
IF not exists ...
BEGIN
   ALTER TABLE ...
END

次に、データベースを新しいスキーマに更新するときに実行するすべての部分を参照するxmlファイルがあります。これは次のようになります。

<playlist>
   <classes>
     <class name="table" desc="Table creation" />
     <class name="schema" desc="Table optimization" />
   </classes>
   <dbschema>
      <steps db="a_database">
         <step file="tbl_Foo.sql" part="create" class="table" />
         <step file="tbl_Bar.sql" part="create" class="table" />
      </steps>
      <steps db="a_database">
         <step file="tbl_Foo.sql" part="addtimestamp" class="schema" />
      </steps>
   </dbschema>          
</playlist>

<classes/>GUIの場合、および<dbschema/>withの部分<steps/>は、変更を分割することです。：<step/>sは順番に実行されます。sqlclrバイナリファイルのデプロイなど、さまざまなことを行うようなエンティティが他にもいくつかありますが、それだけです。

もちろん、そのプレイリストファイルを取得するコンポーネントと、プレイリストを相互参照して必要な部分を取り出し、データベースで管理者として実行するリソース/ファイルシステムオブジェクトがあります。

.sqlの「パーツ」は、任意のバージョンのDBで実行できるように記述されているため、すべてのパーツを以前または古いバージョンのDBで実行し、最新のバージョンに変更できます。もちろん、SQLサーバーが列名を「早期に」解析し、後でパーツをexec_sqlsに変更する必要がある場合もありますが、頻繁には発生しません。

于 2009-04-18T11:54:27.083 に答える
1

SchemaSyncを見てください。データベーススキーマの移行とバージョン管理に必要なパッチと復帰スクリプト（.sqlファイル）を生成します。これは、言語やフレームワークに依存しないMySQLのコマンドラインユーティリティです。

于 2010-04-15T22:01:34.287 に答える
1

数ヶ月前、MySQLスキーマをバージョン管理するためのツールを検索しました。Doctrineの移行、RoRの移行、JavaやPythonで書かれたいくつかのツールなど、多くの便利なツールを見つけました。

しかし、誰も私の要件を満たしていませんでした。

私の要件：

  1. 要件なし、PHPとMySQLを除外
  2. Doctrineのschema.ymlのようなスキーマ構成ファイルはありません
  3. アプリケーションの他のインストールで同一のスキーマを表すよりも、接続から現在のスキーマを読み取り、新しい移行スクリプトを作成することができます。

移行ツールを書き始めましたが、今日はベータ版があります。

このトピックに興味がある場合は、試してみてください。今後のリクエストとバグレポートを送ってください。

ソースコード：bitbucket.org/idler/mmp/src英語の概要：bitbucket.org/idler/mmp/wiki/ロシア語のホーム概要：antonoff.info/development/mysql-migration-with-php-project

于 2010-07-07T21:27:11.627 に答える
1

Our solution is MySQL Workbench. We regularly reverse-engineer the existing Database into a Model with the appropriate version number. It is then possible to easily perform Diffs between versions as needed. Plus, we get nice EER Diagrams, etc.

于 2010-07-07T21:31:00.387 に答える
1

I think this question deserves a modern answer so I'm going to give it myself. When I wrote the question in 2009 I don't think Phinx already existed and most definitely Laravel didn't.

Today, the answer to this question is very clear: Write incremental DB migration scripts, each with an up and a down method and run all these scripts or a delta of them when installing or updating your app. And obviously add the migration scripts to your VCS.

As mentioned in the beginning, there are excellent tools today in the PHP world which help you manage your migrations easily. Laravel has DB migrations built-in including the respective shell commands. Everyone else has a similarly powerful framework agnostic solution with Phinx.

Both Artisan migrations (Laravel) and Phinx work the same. For every change in the DB, create a new migration, use plain SQL or the built-in query builder to write the up and down methods and run artisan migrate resp. phinx migrate in the console.

于 2015-03-13T01:43:51.930 に答える
0

定期的に（2か月に1回）更新する「マスター」ファイル（master.sql）があることを除いて、Manosと同様のことを行います。次に、変更ごとに、変更を含む.sqlファイルという名前のバージョンを作成します。このようにして、master.sqlから始めて、現在のバージョンに到達するまで.sqlファイルという名前の各バージョンを追加し、.sqlファイルという名前のバージョンを使用してクライアントを更新して作業を簡単にすることができます。

于 2009-08-03T12:24:55.957 に答える