数据库版本控制计划：热门与否？

2023年5月17日 182次阅读

基于在网上阅读,堆栈溢出,以及大部分
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

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

最佳答案 看看你的建议,看起来似乎不可行也不实用.

我在一家公司工作,我们每个数据库使用超过1k个表(非常复杂的系统),这一切都运行良好,如下所示：

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

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

>开发人员数据库(本地) – 开发人员用来测试他的工作的数据库.他总是可以从Master或Test Master复制.
>主数据库 – 具有所有默认值的数据库,如果您正在重新部署到新客户端,则可能是半空的.
>测试主数据库 – 填充测试数据的主数据库.您在Master上运行的任何脚本也都在这里运行.
>测试进行中数据库 – 从Test Master复制并用于测试 – 在任何新测试之前被覆盖.
>如果您有分支(类似的数据库,每个客户端略有不同),那么每个分支的分支都与上面相同…

您肯定必须对此进行修改以符合您的情况,但无论如何我认为保持整个数据库的创建脚本的文本版本在可维护性,合并,更新等方面是错误的…

点赞