数据库版本控制 - 分支切换如何工作？

Question

对于那些在开发团队中进行开发的人来说，这是一个问题，其中所有人都有单独的数据库。您使用源代码控制和其他工具对数据库进行版本控制，这些工具将自动将开发数据库更新为最新版本的数据库（架构、数据、SP、函数等）。

好的，太好了！但是等等！如果您正在软件 4.0 版本上进行开发，但现在需要将分支切换到 3.2 分支来修复错误，该怎么办？现在，模式可能（几乎肯定是）非常不同......

我想如果您付出额外的努力来编写回滚脚本以及更改脚本，这可能会起作用。但这看起来工作量很大——真的值得吗？

Answer 1

创建一个新的 3.2 分支数据库并在处理 3.2 分支代码时使用该数据库会更容易。在我看来，要求每个开发人员都只有一个数据库可以使用是不合理的。

Answer 2

我假设您正在将数据库版本化为二进制文件？如果您的所有数据库资产都是构造性代码的形式（例如 SQL 脚本和/或文本数据转储），那么解决方案将很简单，正如 Mark 所建议的：将这些资产存储为开发分支的一部分。要在版本 3.2 上工作，请切换分支，重新运行创建脚本和 presto，3.2 数据库。合并将与常规代码一样简单（或者同样痛苦，具体取决于您选择的版本控制系统）。

以下是在此模式下工作的一些建议：

• 如果从文本创建数据库实例太慢，请在共享磁盘卷上创建一个缓存，并以所有架构/数据文件的内容（或其 MD5 总和）为关键字。
• 编写预提交挂钩，以确保开发人员实例中的架构和数据转储与版本控制下的相同。这可以防止人们使用交互式工具对其开发数据库进行更改，然后忘记提交它们。
• 您提到更改脚本；将它们视为一种责任。虽然您的部署方案可能需要它们（例如，对于想要就地升级的客户），但它们会复制数据库版本历史记录中的信息，并且根据墨菲定律，复制意味着迟早会失去同步。尝试使用“diff”从版本化数据库资产自动生成更改脚本；或者，如果无法实现这一点，请专门对数据库升级进行一些认真的单元测试。