对于那些在一个开发团队中开发的人来说，这是一个问题，你们所有人都有单独的数据库。您正在使用源代码控制和其他工具对数据库进行版本控制，这些工具会自动将开发数据库更新到最新版本的数据库（模式、数据、SP、函数等）。
好，很好！可是等等！如果您正在开发软件的 4.0 版本，但现在需要将分支切换到 3.2 分支来修复错误怎么办？到目前为止，架构可能（几乎可以肯定是）非常不同......
我想，如果您通过额外的努力来编写回滚脚本和更改脚本，这可能会奏效。但这似乎需要做很多工作——真的值得吗？
问问题
361 次
2 回答
1
更容易的是创建一个新的 3.2 分支数据库并在处理 3.2 分支代码时使用它。在我看来，要求每个开发人员都只有一个数据库可以使用似乎是不合理的。
于 2010-09-10T15:53:53.183 回答
0
我正在冒险并假设您将数据库版本控制为二进制文件？如果您的所有数据库资产都采用构造代码的形式（例如 SQL 脚本和/或文本数据转储），那么解决方案将很简单，正如 Mark 所建议的：将这些资产存储为开发分支的一部分。要在版本 3.2 上工作，请切换分支，重新运行创建脚本和 presto，3.2 数据库。合并就像使用常规代码一样容易（或者同样痛苦，取决于您选择的版本控制系统）。
以下是在此模式下工作的一些建议：
- 如果从文本创建数据库实例太慢，请在共享磁盘卷上进行缓存，以所有模式/数据文件的内容（或其 MD5 总和）为键。
- 编写一个预提交钩子以确保开发者实例中的模式和数据转储与版本控制下的相同。这可以防止人们使用交互式工具对其开发数据库进行更改，然后忘记提交它们。
- 您提到更改脚本；将它们视为一种责任。虽然您的部署方案可能需要它们（例如，对于想要就地升级的客户），但它们会从数据库的版本历史记录中复制信息，并且根据墨菲定律，复制迟早意味着不同步。尝试使用“diff”从版本化的数据库资产中自动生成更改脚本；或者如果这无法实现，则将一些严肃的单元测试专门用于数据库升级。
于 2010-09-13T09:30:05.193 回答