4

基于在网上阅读、堆栈溢出以及大多数与编码恐怖相关的关于 db 版本控制的文章，我已经尝试编写一个计划来对一个 8 年历史的 php mysql 网站的数据库进行版本控制。

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

我的第一个问题是，这听起来正确吗？
我的第二个问题是，每天多次执行提交过程似乎有点复杂。有没有办法可靠地自动化它？或者我不应该经常提交数据库更改以使其重要吗？

4

1 回答 1

2

看你的提议，这似乎既不可行也不实用。我在一家公司工作，我们每个数据库使用超过 1k 个表（非常复杂的系统），并且一切正常，如下所示：

  • 有一个负责数据库的人（我们称他为 DBPerson） - 每个脚本/数据库更改都必须通过他。这将避免任何不必要的更改，以及对问题的一些“忽视”（例如，如果有人移动索引以更好地执行他的查询，hi 可能会破坏其他人的工作，也许有人会创建一个完全冗余和不必要的表， ETC...）。这将使数据库保持清洁和高效。即使看起来这对一个人（或他的副手）来说工作量太大，但实际上并非如此——数据库通常很少改变。
  • 每个脚本都必须通过 DBPerson 验证
  • 当脚本被批准后，DBPerson 会分配一个编号并将其放入“更新”文件夹/svn(...) 中，并带有适当的编号（如您所建议的，例如递增编号）。
  • 接下来，如果您有一些持续集成，脚本会被拾取并更新数据库（如果您没有持续集成，请手动执行）。
  • 不要存储整个数据库脚本，以及脚本中的所有数据。而是存储实际的数据库。如果您有解决方案的分支 - 每个分支都有自己的数据库，或者您始终可以为每个分支划分更新脚本，以便您可以回滚/转发到另一个分支。但是，我真的建议每个分支都有一个单独的数据库。
  • 拥有一个始终包含默认数据（完整）的数据库 - 以满足单元测试、回归测试等的需求。无论何时进行测试，都应在该数据库的副本上进行。您甚至可以使用主数据库对测试数据库进行夜间清理（当然，如果合适的话）。

在这样的环境中，您将拥有多个版本的数据库：

  • 开发人员数据库（本地）- 开发人员用来测试他的工作的数据库。他总是可以从大师或测试大师那里复制。
  • 主数据库 - 具有所有默认值的数据库，如果您正在重新部署到新客户端，则可能是半空的。
  • 测试主数据库 - 充满测试数据的主数据库。您在 Master 上运行的任何脚本也在这里运行。
  • 正在进行的测试数据库 - 从测试主数据库复制并用于测试 - 在任何新测试之前被覆盖。
  • 如果您有分支（每个客户端的类似数据库略有不同），那么每个分支都将具有与上述相同的...

您当然必须对此进行修改以匹配您的情况，但无论如何我认为保留整个数据库的创建脚本的文本版本在可维护性、合并、更新等方面是错误的......

于 2010-12-03T12:01:06.460 回答