数据库架构升级检查表

Question

由于必须升级数据库模式，因此安装新版本的软件要困难得多。这样做的最佳做法是什么？

我正在寻找一份清单或行动项目的时间表，例如

• 8:30关闭应用程序
• 8:45修改模式
• 9:15安装新应用程序
• 9:30重新启动db

等等，展示如何最小化风险和停机时间。问题，如

• 如果事情出了问题，退出升级
• 最小化对现有应用程序的影响
• 数据库运行时的“热”更新
• 从dev到test升级到生产服务器

特别有趣。

Answer 1

我在这方面有很多经验。我的应用程序是高度迭代的，而且模式更改经常发生。我大约每2到3周发布一次产品发行版，我的FogBugz列表中每一个项目都有50-100个项目被清除。我们在过去几年中所做的每一个版本都需要模式更改来支持新特性。

关键是在测试环境中进行几次修改，然后才能在实际的服务器上执行这些更改。

我保留了一个部署清单文件，该文件是从模板复制而来的，然后对每个版本进行了大量编辑，其中包含了任何不寻常的内容。

我有两个在数据库上运行的脚本，一个用于模式更改，一个用于可编程性(过程、视图等)。更改脚本是手工编写的，而带有procs的修改脚本是通过Powershell编写的。更改脚本在关闭所有内容时运行(您必须选择一个会使最少的用户为此烦恼的时间)，并且它是通过命令手动运行的，以防有任何异常发生。我遇到的最常见的问题是添加一个由于重复行而失败的唯一约束。

在准备集成测试周期时，我会在测试服务器上检查检查表，就好像该服务器正在生产一样。然后，除此之外，我将得到生产数据库的一个实际副本(这是一个很好的时间来交换您的离站备份)，并且我在恢复的本地版本上运行脚本(这也很好，因为它证明我最近的备份是正确的)。我在这里用一块石头杀了很多鸟。

总共有4个数据库：

1. Dev:所有的更改都必须在更改脚本中进行，永远不要使用studio。
2. 测试:集成测试在这里进行
3. 制作副本:最后一分钟部署实践
4. 生产

你真的真的需要把它做对，当你在生产中。备份架构更改是很困难的。

至于修补程序，我只会修复过程，永远不会架构，除非这是一个非常孤立的更改，对业务至关重要。

Answer 2

我想你已经考虑过斯考特·安布勒？http://www.agiledata.org/essays/databaseRefactoring.html的读物了

Answer 3

这是我在工作中刚刚谈到的一个话题。主要问题是，除非您的框架(如rails及其迁移脚本)很好地为您处理数据库迁移，否则它将由您决定。

我们目前的做法显然存在缺陷，我愿意听取其他建议。

1. 拥有一个包含静态数据的模式转储，这些数据需要保持在最新的版本控制中。
2. 每次执行模式更改操作时，请更改、创建等，将其转储到文件中，并将其抛到版本控制中。
3. 确保更新原始sql转储。
4. 在执行推送操作时，请确保您或您的脚本将sql文件应用于数据库。
5. 清理在版本控制中的旧sql文件，因为它们变旧了。

这绝不是最优的，实际上并不打算作为“备份”db。这只是为了让开发人员轻松地生活，并让开发人员保持在同一个页面上。对于自动化sql文件到数据库的应用程序，您可能可以使用capistrano设置一些很酷的东西。

特定于Db的版本控制会非常棒。也许会有这样的事情，如果没有的话，也许应该有。