4

Webの周りを読んだり、スタックオーバーフローをしたり、コーディングホラーからリンクされたdbバージョン管理に関するこれらの記事のほとんどに基づいて、8年前のphpmysqlWebサイトのデータベースをバージョン管理する計画を立てました。

Database Version Control plan
- Create a db as the "Master Database"
- Create a table db_version (id, script_name, version_number, author, comment, date_ran)   
- Create baseline script for schema+core data that creates this db from scratch, run this on Master Db
- Create a "test data" script to load any db with working data
- Modifications to the master db are ONLY to be made through the db versioning process
- Ensure everyone developing against the Master Db has a local db created by the baseline script
- Procedures for commiting and updating from the Master Db
    - Master Db Commit
        - Perform a schema diff between your local db and the master db
        - Perform a data diff on core data between your local db and master db
        - If there are changes in either or both cases, combine these changes into an update script
        - Collect the data to be added to a new row in db_version table, and add an insert for this into the script
            - new version number = latest master db version number +1
            - author
            - comment
        - The script must be named as changeScript_V.sql where V is the latest master db version +1
        - Run the script against the master db
        - If the script executed succesfully, add it to the svn repository
        - Add the new db_version record to your local db_version table      
    - Update from Master Db
        - Update your local svn checkout to have all the latest change scripts available
        - compares your local db_version table to the master db_version table to determine which change scripts to run
        - Run the required change scripts in order against your local db, which will also update your local db_version table

私の最初の質問は、この音は正しいですか？
私の2番目の質問は、コミットプロセスは、1日に2回以上実行するのは少し複雑に思えます。それを確実に自動化する方法はありますか？または、データベースの変更を問題になるほど頻繁にコミットするべきではありませんか？

4

1 に答える 1

2

あなたの提案を見ると、それは実行可能でも実用的でもないように思えます。私はデータベースごとに1,000を超えるテーブルを使用している会社（非常に複雑なシステム）で働いていましたが、すべて次のように正常に機能しました。

  • DBを担当する人を1人配置します（彼をDBPersonと呼びます）-すべてのスクリプト/dbの変更は彼を通過する必要があります。これにより、不要な変更が回避され、問題の「見落とし」が発生します（たとえば、誰かがインデックスを移動してクエリのパフォーマンスを向上させた場合、他の人の作業が破壊されたり、完全に冗長で不要なテーブルが作成されたりする可能性があります、など...）。これにより、dbがクリーンで効率的に保たれます。これは一人の男（または彼の代理人）にとっては大変な作業のように見えても、実際にはそうではありません-通常、dbはめったに変更されません。
  • 各スクリプトは、DBPersonを介して検証に合格する必要があります
  • スクリプトが承認されると、DBPersonは番号を割り当て、適切な番号（たとえば、増分番号）を付けて'update'フォルダー/svn（...）に配置します。
  • 次に、継続的インテグレーションが実施されている場合、スクリプトが取得され、データベースが更新されます（継続的インテグレーションがない場合は、手動で実行してください）。
  • すべてのデータをスクリプトに含めて、データベーススクリプト全体を保存しないでください。代わりに実際のデータベースを保存してください。ソリューションのブランチがある場合-各ブランチに独自のデータベースを用意するか、ブランチごとに更新スクリプトをいつでも分割して、別のブランチにロールバック/転送できるようにすることができます。ただし、ブランチごとに個別のデータベースを用意することを強くお勧めします。
  • 単体テスト、回帰テストなどのニーズに対応するために、常にデフォルトデータ（インタクト）を備えたデータベースを1つ用意します。テストを実行するときは常に、このデータベースのコピーで実行してください。テストデータベースをメインデータベースで毎晩クリーンアップすることもできます（もちろん適切な場合）。

このような環境では、データベースの複数のバージョンがあります。

  • 開発者データベース（ローカル）-開発者が自分の作業をテストするために使用しているデータベース。彼はいつでもマスターまたはテストマスターからコピーできます。
  • マスターデータベース-すべてのデフォルト値を持つデータベース。新しいクライアントに再デプロイする場合は、半空になる可能性があります。
  • テストマスターデータベース-テストデータで満たされたマスターデータベース。ここで実行したマスターで実行したスクリプトもすべてここで実行します。
  • テスト進行中のデータベース（テストマスターからコピーされ、テストに使用される）は、新しいテストの前に上書きされます。
  • ブランチ（クライアントごとにわずかに異なる類似のデータベース）がある場合は、ブランチごとに上記と同じになります...

状況に合わせてこれを変更する必要がありますが、とにかく、データベース全体の作成スクリプトのテキストバージョンを維持することは、保守性、マージ、更新などの点で間違っていると思います...

于 2010-12-03T12:01:06.460 に答える