必须升级数据库架构使得安装新版本的软件变得非常棘手。最佳做法是什么？

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

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

等，展示如何最大程度地减少风险和停机时间。诸如

• 如果出现问题，请退出升级
• 最大限度地减少对现有应用程序的影响
• 数据库运行时"热"更新
• 从开发到测试到生产服务器的升级

特别令人感兴趣。

解决方案

回答

我想我们已经考虑过斯科特·安布勒(Scott Ambler)的读物吗？
http://www.agiledata.org/essays/databaseRefactoring.html

回答

这是我在工作中谈论的话题。主要的问题是，除非框架为我们很好地处理了数据库迁移(例如，rails及其迁移脚本)，否则将由我们自己决定。

当前我们这样做的方式存在明显的缺陷，我愿意接受其他建议。

• 使用静态数据进行模式转储，该数据必须保持最新并处于版本控制中。
• 每次执行模式更改操作时，都要进行ALTER，CREATE等操作，将其转储到文件中并放入版本控制中。
• 确保我们更新了原始的sql db dump。
• 进行实时推送时，请确保我们或者脚本将sql文件应用于数据库。
• 清理旧的版本控制中的旧sql文件。

这绝不是最佳选择，实际上也不是要用作"备份"数据库。这仅仅是为了使生活变得容易，并使开发人员保持在同一页面上。可以使用capistrano设置一些很酷的功能，只要将sql文件的应用程序自动化到数据库即可。

特定于db的版本控制非常棒。可能有某种方法可以做到这一点，如果没有，应该应该有。

回答

我对此有很多经验。我的应用程序是高度迭代的，并且架构更改经常发生。我大约每2至3周进行一次生产发布，从我的FogBugz列表中清除了50-100件产品。过去几年中，我们完成的每个版本都需要更改架构以支持新功能。

这样做的关键是要在测试环境中多次实践更改，然后才能在实时服务器上实际进行更改。

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

我有两个在数据库上运行的脚本，一个用于模式更改，一个用于可编程性(过程，视图等)。更改脚本是手工编写的，带有proc的脚本是通过Powershell编写的。更改脚本在所有功能都关闭时运行(我们必须为此花费最少的时间来烦扰用户)，并且手动运行命令逐个命令运行，以防万一出现异常情况。我遇到的最常见的问题是添加唯一约束，该约束由于重复的行而失败。

在准备集成测试周期时，我在测试服务器上仔细检查了清单，好像该服务器是生产服务器一样。然后，除此之外，我还获得了生产数据库的实际副本(这是交换非现场备份的好时机)，并且我在还原的本地版本上运行了脚本(这也很好，因为它证明了我的最新备份是正确的)。我在这里用一块石头杀了很多鸟。

因此，总共有4个数据库：

• 开发人员：所有更改都必须在更改脚本中进行，而不能在Studio中进行。
• 测试：此处进行集成测试
• 生产副本：最后一分钟的部署实践
• 生产

在生产过程中，我们确实非常需要正确处理。撤消架构更改非常困难。

就修补程序而言，我将永远不会执行修补程序过程，而不会涉及架构，除非它是一个非常孤立的更改并且对业务至关重要。

回答

并且，如果Scott Ambler的论文引起胃口，我可以推荐他与Pramod J Sadolage一起撰写的名为"重构数据库"的书http://www.ambysoft.com/books/refactoringDatabases.html

Yahoo的敏捷数据库小组(http://tech.groups.yahoo.com/group/agileDatabases/)上也有很多有用的建议和信息。

回答

快速注意两点：

• 不用说...所以我要说两次。确认我们具有有效的备份。确认我们具有有效的备份。
• @mk。查看Jeff关于数据库版本控制的博客文章(如果还没有的话)