我正在为新的Web应用程序开发部署系统，我想知道管理数据库迁移过程中最好的一点是什么（如何进行迁移的问题完全是另一个问题）
似乎有两种方法：
有没有人对这些方法有任何建议/见解/经验？还有其他建议吗？
我可以看到为什么＃1可能更具吸引力 - 它让我可以完全控制数据库何时更新。但是，我非常喜欢＃2，因为它允许我在部署之间快速迭代并减少手动过程。 ＃2也可以在我的开发机器上使用，以便更快地进行迭代。嗯，开始认为两者都可能是件好事......
答案 0 :(得分：2)
我们有一个带有~100客户端的销售系统，我们正在应用程序启动时更新数据库（True，我们是桌面应用程序。）我喜欢这种方法，如果我们有不确定的起点，它是安全的和迭代的（是客户端）数据库新的或只更新到verison xyz？）。
但是在服务器端，我更喜欢你的＃1选项：我们在虚拟机上创建一个SQL查询文件（基于原始数据库的副本）并对真实服务器运行此查询。
恕我直言：
所以我也对这个问题感兴趣，并发现一些（一半）框架为RikMigrations。经过一些谷歌搜索后，有一个关于数据库版本/迁移框架的良好开端：.NET Database Migration Tool Roundup。不是必要的文档，但团队博客可以是有趣的。
答案 1 :(得分：1)
我更喜欢选项＃1，因为它似乎更灵活。代替在每个应用程序启动时实际执行迁移，我想我会验证数据库架构（版本号？）是否与代码匹配，如果不匹配，则抛出有关不匹配的数据库架构的警告或错误。
答案 2 :(得分：0)
出于多种原因，我更喜欢选项＃1。首先，集成测试通常要求您的数据库架构是最新的，并且启动网站来升级架构将是一个巨大的时间。其次，您无法在站点运行时更改数据库架构（例如，添加几个索引以加快速度）。
对于生产方面的事情，在事务MSI样式安装中升级数据库比尝试在每个应用程序启动时升级要好得多，因为您可能最终得到去同步的数据库应用程序版本。
如果您正在寻找迁移框架，请查看Wizardby。
答案 3 :(得分：0)
如果应用程序必须在客户机器上运行而不是在启动时迁移可能会阻止大量支持调用 - 假设您可以在没有用户干预的情况下进行无缝迁移（我希望您通常不会运行您的Web应用程序并获得许可修改数据库）。
如果应用程序始终在您的控制下运行，则自动迁移不是问题 - 但仍然可以是一个很好的功能，特别是如果您希望最大限度地减少停机时间和手动部署步骤。