您使用什么方法对数据库进行版本控制？我已将所有数据库表作为单独的.sql脚本提交到我们的存储库(mercurial).这样,如果团队中的任何成员对employee表进行了更改,那么,当我更新我的存储库时,我将立即知道哪个特定表已被修改.

这种方法描述于：What are the best practices for database scripts under code control.
目前,我正在编写一个python脚本来执行数据库文件夹中的所有.sql文件,但是,由于外键约束导致的依赖性问题确保我们不能只按任何顺序运行.sql文件.

python脚本用于生成一个文件,其中包含执行.sql文件的顺序.它将按照它们出现在tableorder.txt文件中的顺序执行.sql文件.在执行外键表之前,不能执行表,例如：

tableorder.txt

table3.sql
table1.sql
table7.sql等

我已经通过解析“show create table”mysql命令的结果,从代码中为每个表生成了依赖列表.因此依赖性列表可能是这样的：

tblstate: tblcountry //tblcountry.sql must be executed before tblstate.sql etc
tblemployee: tbldepartment, tblcountry

要生成tableorder.txt的内容,我需要一个看起来如此的算法：

function print_table(table):
  foreach table in database:
    if table.dependencies.count == 0
      print to tableorder.txt
    if table.dependencies.count > 0
      print_table(dependency) //print dependency first
end function

正如您将想象的那样,这涉及到大量的递归.我开始怀疑它是否值得付出努力？如果那里有一些工具？有什么工具(或算法)可以生成执行单独的.sql表和视图的顺序列表,同时考虑依赖性？是否更好地为每个表/视图版本控制单独的.sql文件或更好地将版本控制整个数据库到单个.sql文件？我会感谢任何回应,因为这已经花了这么多天.谢谢.

解决方法:

我不使用MySQL,而是使用SQL Server,但是,这是我对数据库的版本：

(这很长,但最后我希望我放弃一个简单的模式转储作为处理数据库版本控制的主要方法的原因很明显.)

>我对模式进行了修改并将其应用于测试数据库.
>我在所述脚本之后生成增量更改脚本和模式转储. (我使用ApexSQL,但可能有MySQL特定的工具可以提供帮助.)

>增量更改脚本知道如何从当前模式版本到目标模式版本：ALTER TABLE existing,CREATE TABLE new,DROP VIEW old ..多个操作可以在同一个.SQL文件中发生,因为delta非常重要.
>模式的转储是目标模式版本：CREATE TABLE a,CREATE VIEW b ..这里没有“ALTER”或“DROP”,因为它只是目标模式的快照.每个数据库对象都有一个.SQL文件,因为模式很重要.

>我使用RoundhousE来应用增量更改脚本. (我不使用RoundhousE“随时脚本”功能,因为这不能正确处理关系.)

我学到了如果没有全面的逐步计划就无法可靠地完成应用数据库模式更改的困难方法,并且类似地(如问题中所述),关系依赖关系的顺序很重要.仅存储“当前”或“结束”模式是不够的.有许多变化不能追溯地应用A-> C而不知道A-> B-> C并且一些变化B可能涉及迁移逻辑或校正. SQL架构更改脚本可以捕获这些更改并允许它们“重放”.

但是,同时仅保存增量脚本不会提供目标模式的“简单视图”.这就是我也转储所有架构以及更改脚本和版本的原因.从理论上讲,视图转储可用于构建数据库,但由于关系依赖性(问题中提到的那种),可能需要一些工作,我不会将其用作自动模式恢复方法的一部分：但是,保持Hg版本控制的模式转储部分可以快速识别更改并查看特定版本的目标模式.

因此,更改增量将在修订版中向前移动,而架构转储在当前版本中提供视图.因为更改增量是增量和仅向前,所以保持处理这些更改的分支“干净”很重要,这很容易用Hg完成.

在我的一个项目中,我目前正在更改数据库70 – 并且快乐且富有成效！ – 切换到此设置后. (这些是部署的变更,而不仅仅是开发变更！)

快乐的编码.