数据库迁移：使用构建脚本管理还是在应用程序启动时自动迁移？答案

【问题标题】：Database migrations: manage with build script or automatic on app startup?数据库迁移：使用构建脚本管理还是在应用程序启动时自动迁移？
【发布时间】：2010-10-19 15:12:08
【问题描述】：

我正在为新的 Web 应用程序开发部署系统，我想知道管理数据库迁移过程中的最佳点在哪里（如何进行迁移的问题完全是另一个问题） .

看来有两条路可以走：

使用迁移脚本可以要么从命令手动运行线或作为自动的一部分部署/构建过程
当应用程序运行迁移启动（我正在使用 ASP.NET 所以这个可以很容易地完成而无需导致长时间运行的用户请求）

是否有人对这些方法有任何建议/见解/经验？还有其他建议吗？

我明白为什么 #1 可能更有吸引力 - 它让我可以完全控制数据库的更新时间。但是，我非常喜欢 #2，因为它允许我在部署之间快速迭代并减少手动过程。 #2 也可以在我的开发机器上使用，以允许更快的迭代。嗯，开始觉得两者兼备可能是件好事……

【问题讨论】：

标签： deployment build-process database-migration

【解决方案1】：

我更喜欢选项#1，因为它看起来更灵活。代替在每个应用程序启动时实际执行迁移，我想我会验证数据库架构（版本号？）是否与代码匹配，如果不匹配，则抛出有关数据库架构不匹配的警告或错误。

【讨论】：

【解决方案2】：

我们有一个拥有约 100 个客户端的销售团队系统，我们在应用程序启动时更新数据库（确实，我们是一个桌面应用程序。）我喜欢这种方法，如果我们有不确定的起点（是客户端数据库是新的还是仅更新到 xyz 版本？）。

但在服务器端，我更喜欢您的#1 选项：我们在虚拟机上创建一个 SQL 查询文件（基于原始数据库的副本）并针对真实服务器运行此查询。

所以恕我直言：

断开连接的客户端：启动、迭代脚本
服务器：根据实际和真实数据库在VM上创建查询

所以我也对这个问题感兴趣，并找到一些（一半）框架作为RikMigrations。经过一番谷歌搜索，有一个关于数据库版本控制/迁移框架的好起点：.NET Database Migration Tool Roundup。不一定是文档，但团队博客可能很有趣。

【讨论】：

【解决方案3】：

出于多种原因，我更喜欢选项 #1。首先，集成测试通常需要您的数据库模式是最新的，并且启动一个网站来升级模式将是一个巨大的浪费时间。其次，您不能在网站运行时更改数据库架构（例如，添加几个索引以加快速度）。

就生产方面而言，在事务 MSI 样式安装中升级数据库比在每次应用启动时尝试升级要好得多，因为您最终可能会得到不同步的数据库应用版本。

如果您正在寻找迁移框架，请查看Wizardby。

【讨论】：

【解决方案4】：

如果应用程序必须在客户的机器上运行，那么在启动时进行迁移可以避免大量的支持呼叫 - 假设您可以在没有用户干预的情况下进行无缝迁移（我希望您通常不会运行您的网络应用程序并获得以下权限）修改数据库）。

如果应用程序始终在您的控制下运行，则自动迁移问题不大 - 但仍然是一个很好的功能，特别是如果您希望最大限度地减少停机时间和手动部署步骤。

【讨论】：