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

Question

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

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

我想如果您经过额外的努力来编写回滚脚本以及更改脚本，这可能会有效。但这似乎很多工作 - 它真的值得吗？

Answer 1

更容易创建一个新的3.2分支数据库，并在处理3.2分支代码时使用它。我要求每个开发人员只有一个数据库可供使用似乎不合理。

Answer 2

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

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

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