【发布时间】：2009-08-26 22:00:47
【问题描述】：
警告：问题很长。
[问题]
如果策略是每个数据库都有一个分支，如下面的问题所述，其中脚本受版本控制。
在尝试合并到更少的分支机构时如何管理数据迁移问题？
这只是数据迁移的一部分吗？
基本上必须在迁移时创建转换脚本。
有更好的方法吗？
我们可以同时解决这两个问题吗？
最佳做法是什么？
[背景]
在我的工作地点，我们的产品有 3 个分支。主线具有“最新和最伟大”的更改，无需准备好发布。
- B 版（名称已更改以保护有罪者）
- A 版（已更改名称以保护有罪者）
- 主线
由于这些分支，数据库实际上有 3 个版本。 代码版本控制相当容易，但数据库版本控制似乎很困难。
已阅读Do you use source control for your database items? 似乎最好的方法是导出每个对象/表的所有创建脚本。 注意：根据文章，您如何管理它，在一个大脚本或多个脚本或混合中，是您的偏好。
我同意这一点，并询问了为什么没有这样做。
目前 DBA 拒绝将脚本分支到分支中。 除了懒惰作为借口之外，原因是为了节省数据迁移的时间。 实际上，所有版本都强制维护数据库更改。
所有脚本都受版本控制，仅在主线中维护。 版本 A 和版本 B 有他们自己的特殊文件，说明哪些更改脚本要在各自的分支上运行。当有更改脚本时会出现问题，例如应用于版本 A 但版本 B 只需要部分更改。由开发人员通知 DBA 更新文件，该文件指示为每个分支应用哪些补丁。对于执行过多手动干预的更改脚本，需要手动应用部分更改脚本。
要在版本 A 上更新数据库，所有补丁都将与版本 A 一起提取要应用文件的补丁。
[场景]
- 存在以上 3 个版本。
- 版本 A 发生数据库更改。
- 分支合并，其中代码从版本 B 合并到 A，以便可以删除版本 B。
- 数据库也需要这样做。
希望这是有道理的。
【问题讨论】：
-
您能否澄清一下您的任何数据库脚本当前是否受版本控制？或者您是否计划在未来使用源代码控制来维护数据库的多个分支？另外，您的问题是关于如何频繁合并数据库还是只合并一次以完全摆脱分支？
-
我已经澄清了上面的问题。似乎版本控制策略只是因为要避免分支，因为我无法理解的原因。我认为我对这个问题的理解是因为数据迁移有很大的成本。但是正如 John Saunders 在下面所说的，在最初创建更改脚本时通常会考虑到这一点。感谢所有的帮助家伙。似乎正常的版本控制策略毕竟会起作用。