数据库版本控制计划：热不热？

Question

基于在网络上阅读、堆栈溢出以及大多数 这些关于数据库版本控制的文章来自编码恐怖，我尝试编写一个计划来对一个已有 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 上运行的任何脚本也可以在这里运行。
• 正在进行的测试数据库 - 从测试主复制并用于测试 - 在任何新测试之前被覆盖。
• 如果您有分支（类似的数据库，每个客户端略有不同），那么您的每个分支将具有与上面相同的...

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