4

データベースのバージョン管理にどのような方法を使用していますか? すべてのデータベース テーブルを個別の .sql スクリプトとしてリポジトリ (mercurial) にコミットしました。そうすれば、たとえば、チームのメンバーが従業員テーブルを変更した場合、リポジトリを更新したときに変更された特定のテーブルがすぐにわかります。

このような方法については、「コード制御下のデータベース スクリプトのベスト プラクティスとは」で説明されています。現在、データベース フォルダー内のすべての .sql ファイルを実行する python スクリプトを作成していますが、外部キー制約による依存関係の問題により、.sql ファイルを任意の順序で実行することはできません。

Python スクリプトは、.sql ファイルを実行する順序でファイルを生成することです。tableorder.txt ファイルに表示される順序で .sql ファイルを実行します。テーブルは、その外部キー テーブルが実行されるまで実行できません。次に例を示します。

tableorder.txt

table3.sql
table1.sql
table7.sql など

既に、"show create table" mysql コマンドの結果を解析して、コードから各テーブルの依存関係リストを生成しています。依存関係リストは次のようになります。 

tblstate: tblcountry //tblcountry.sql must be executed before tblstate.sql etc
tblemployee: tbldepartment, tblcountry

tableorder.txt のコンテンツを生成するには、次のようなアルゴリズムが必要です。

function print_table(table):
  foreach table in database:
    if table.dependencies.count == 0
      print to tableorder.txt
    if table.dependencies.count > 0
      print_table(dependency) //print dependency first
end function

ご想像のとおり、これには多くの再帰が含まれます。努力する価値があるかどうか疑問に思い始めています。そこにツールがあれば？依存関係を考慮して個別の .sql テーブルとビューを実行する順序のリストを生成するツール (またはアルゴリズム) は何ですか? テーブル/ビューごとに個別の .sql ファイルをバージョン管理する方が良いですか、それともデータベース全体を単一の .sql ファイルにバージョン管理する方が良いですか? これには何日もかかったので、どんな返事でも感謝します。ありがとう。

4

4 に答える 4

4

私は MySQL ではなく SQL Server を使用していますが、これがデータベースのバージョン管理方法です。

(これは長いですが、最後に、データベースのバージョン管理を処理する主要な方法として単純なスキーマ ダンプを放棄する理由が明らかになることを願っています。)

  1. スキーマに変更を加えて、テスト データベースに適用します。

  2. デルタ変更スクリプトを生成し、スクリプトの後にスキーマのダンプを生成します。(私は ApexSQL を使用していますが、MySQL 固有のツールが役立つ可能性があります。)

    1. デルタ変更スクリプトは、現在のスキーマ バージョンからターゲット スキーマ バージョンに移行する方法を認識しています: ALTER TABLE existing、CREATE TABLE new、DROP VIEW old ..デルタが重要であるため、同じ .SQL ファイル内で複数の操作が発生する可能性があります。

    2. スキーマのダンプは、ターゲット スキーマ バージョンのものです。スキーマは重要であるため、データベース オブジェクトごとに 1 つの .SQL ファイルがあります。

  3. RoundhouseE を使用してデルタ変更スクリプトを適用します。(これは関係を正しく処理しないため、RoundhouseE の「いつでもスクリプト」機能は使用しません。)

データベース スキーマの変更を適用することは、包括的な段階的な計画なしでは確実に行うことができないという難しい方法を学びました。同様に (質問に記載されているように)、関係の依存関係の順序が重要です。「現在」または「終了」スキーマを格納するだけでは十分ではありません。A->B->C を知らずに A->C をさかのぼって適用できない多くの変更があり、一部の変更 B には移行ロジックまたは修正が含まれる場合があります。SQL スキーマ変更スクリプトは、これらの変更をキャプチャして、「再生」できるようにすることができます。

ただし、同時に、デルタ スクリプトを保存するだけでは、ターゲット スキーマの「単純なビュー」は提供されません。これが、変更スクリプトとバージョンの両方だけでなく、すべてのスキーマもダンプする理由です。理論的には、ビュー ダンプを使用してデータベースを構築できますが、リレーションシップの依存関係 (質問に記載されている種類) により、多少の作業が必要になる場合があり、自動化されたスキーマ復元アプローチの一部としては使用しません。それでも、Hg バージョン管理のスキーマ ダンプ部分を維持することで、変更をすばやく識別し、特定のバージョンでターゲット スキーマを表示できます。

したがって、変更デルタはリビジョンを進めながら、スキーマ ダンプは現在のリビジョンでのビューを提供します。変更デルタは増分的で前方のみであるため、これらの変更を処理するブランチを「クリーン」に保つことが重要です。これは Hg で簡単に実行できます。

私のプロジェクトの 1 つで、私は現在、データベースの変更番号 70 に達しています。満足しており、生産的です! - このセットアップに切り替えた後。(そして、これらは展開された変更であり、開発の変更だけではありません!)

ハッピーコーディング。

于 2012-07-12T22:56:09.773 に答える
2

sqitchを使用できます。これは MySqlのチュートリアルですが、実際にはデータベースに依存しません。

変更は、選択したデータベース エンジンにネイティブなスクリプトとして実装されます... データベースの変更は、他の Sqitch プロジェクトからの変更であっても、他の変更への依存を宣言する場合があります。これにより、VCS に順不同で変更をコミットした場合でも、適切な実行順序が保証されます... 変更の展開は、プラン ファイルを維持することによって管理されます。そのため、必要に応じて番号を付けることはできますが、変更に番号を付ける必要はありません。Sqitch は、変更にどのように名前を付けるかはあまり気にしません... アプリケーションにタグを付けてリリースするまでは、変更デプロイ スクリプトを何度でも変更できます。VCS にコミットされているという理由だけでロックインされているわけではありません。これにより、反復的なアプローチでデータベース スキーマを開発できます。または、テスト駆動型のデータベース開発を行うことができます。

于 2015-11-25T19:55:39.903 に答える
1

これがあなたの質問にどれだけうまく答えるかはわかりませんが、私は mysqldump (標準インストールの一部) を使用する傾向があります。これにより、テーブルを作成してデータを入力し、データベースを効果的にシリアル化するための sql が得られます。例：

> mysqldump -u username -p yourdatabase > database_dump.sql

ダンプSQLファイルからデータベースをロードするには:

mysql -u ユーザー名 -p -e "ソース /path/to/database_dump.sql"

あなたの質問にさらに答えるために、バージョン管理されている単一のダンプだけで競合が発生する可能性が高い方法でデータベースで作業している複数の人がいる場合にのみ、各テーブルを個別にバージョン管理します。私はこのようなプロジェクトに当たったことはありません (データベースは、プロジェクトの初期段階の後、システムの最も揮発性の低い部分の 1 つになる傾向があります)。そのため、データベース ダンプを個別ではなく全体としてバージョン管理するだけです。個別にテーブル。

于 2012-07-12T22:44:05.710 に答える