数据库版本控制计划 : hot or not?

Question

基于网络阅读、堆栈溢出，主要是 these articles关于与编码恐怖相关的数据库版本控制，我已经尝试编写一个计划来对一个有 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

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

Answer 1

看你们的提议，好像不太可行也不实用。我在一家公司工作，我们每个数据库使用超过 1k 个表(非常复杂的系统)，并且一切正常，如下所示:

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

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

• 开发人员数据库(本地)- 开发人员用来测试他的工作的数据库。他可以随时从 Master 或 Test Master 复制。
• 主数据库 - 具有所有默认值的数据库，如果您要重新部署到新客户，则可能是半空的。
• 测试主数据库 - 包含测试数据的主数据库。您在 Master 上运行的任何脚本也在此处运行。
• 正在进行的测试数据库 - 从 Test Master 复制并用于测试 - 在任何新测试之前被覆盖。
• 如果您有分支机构(类似的数据库，但每个客户略有不同)，那么每个分支机构的数据库都与上述相同...

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