3

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

似乎有两种方法可以去：

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

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

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

4

4 回答 4

2

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

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

所以恕我直言：

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

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

于 2009-04-15T15:56:07.700 回答
1

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

于 2009-04-15T15:52:58.207 回答
0

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

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

于 2009-04-19T19:29:25.843 回答
0

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

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

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

于 2009-04-19T19:19:55.413 回答