python - MySQL 的数据库版本控制

Question

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

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

python 脚本是生成一个文件，其中包含执行.sql 文件的顺序。它将按照 tableorder.txt 文件中出现的顺序执行 .sql 文件。一个表在它的外键表被执行之前不能被执行，例如:

表格顺序.txt

表3.sql
表1.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 表和 View 的顺序列表？对每个表/ View 进行版本控制单独的 .sql 文件更好，还是将整个数据库版本控制为单个 .sql 文件更好？我将不胜感激任何回复，因为这花了很多天。谢谢。

Answer 1

我不使用 MySQL，而是使用 SQL Server，但是，这就是我对我的数据库进行版本控制的方式:

(这很长，但最后我希望我放弃简单模式转储作为处理数据库版本控制的主要方式的原因是显而易见的。)

1. 我对架构进行了修改，将其应用于测试数据库。

2. 我在上述脚本之后生成增量更改脚本和架构转储。 (我使用 ApexSQL，但可能有特定于 MySQL 的工具可以提供帮助。)

   1. 增量更改脚本知道如何从当前模式版本转到目标模式版本:ALTER TABLE existing、CREATE TABLE new、DROP VIEW old .. 多个操作可以在与 相同的 .SQL 文件中发生delta 很重要。

   2. 模式的转储是目标模式版本:CREATE TABLE a，CREATE VIEW b .. 这里没有“ALTER”或“DROP”，因为它只是目标模式的快照。每个数据库对象都有一个 .SQL 文件，因为架构很重要。

3. 我使用 RoundhouseE 来应用增量更改脚本。 (我不使用 RoundhouseE 的“随时脚本”功能，因为它不能正确处理关系。)

我从惨痛的教训中了解到，如果没有全面的分步计划，就无法可靠地应用数据库架构更改，同样地(如问题中所述)，的顺序关系依赖很重要。仅存储“当前”或“结束”模式是不够的。有许多更改不能在不知道 A->B->C 的情况下追溯应用 A->C，并且一些更改 B 可能涉及迁移逻辑或更正。 SQL 架构更改脚本可以捕获这些更改并允许它们“重放”。

然而，与此同时仅保存增量脚本并不能提供目标架构的“简单 View ”。这就是为什么我还转储所有架构以及更改脚本和版本两者。理论上， View 转储可用于构建数据库，但由于关系依赖性(问题中提到的那种)，它可能需要一些工作，我不会将其用作自动模式恢复方法的一部分:然而，保留 Hg 版本控制的模式转储部分允许快速识别更改并查看特定版本的目标模式。

因此，更改增量向前移动 通过修订，而架构转储提供当前修订的 View 。因为更改增量是增量的并且仅向前，所以保持处理这些更改的分支“干净”很重要，这很容易用 Hg 做到。

在我的一个项目中，我目前处于第 70 次数据库更改 - 并且快乐且富有成效! - 切换到此设置后。 (而且这些是已部署的更改，而不仅仅是开发更改!)

快乐编码。