【发布时间】：2010-11-13 08:49:56
【问题描述】：
通常在项目的整个开发过程中，我会经常部署，以确保我不会在生产中遇到任何问题。
此外，在整个开发过程中，我发现自己正在更改数据库的架构。
如何在生产环境中轻松更新数据库？
我一直在删除旧数据库并重新附加新数据库。有没有更快的方法来更新部署数据库？
谢谢
编辑
有哪些免费工具可以做到这一点？
【问题讨论】：
标签： sql sql-server sql-server-2008 schema
【发布时间】：2010-11-13 08:49:56
【问题描述】：
试试 DBSourceTools。
http://dbsourcetools.codeplex.com
它是开源的，并将编写整个数据库的脚本
- 表、视图、过程和数据到磁盘，然后允许您通过部署目标重新创建该数据库。
它专门用于帮助开发人员将他们的数据库置于源代码控制之下。
【讨论】：
Visual Studio 数据库版is quite good at this。它将您的整个模式与您的其余代码一起保存在源代码控制下的源脚本中。当您进行更改时，它可以分析您的架构的依赖关系。它可以运行最佳实践分析。它可以生成一个 .dbschema 文件，部署工具可以使用该文件将您的数据库升级到当前架构。
您实际上可以通过持续集成自动执行此操作，并直接构建测试环境、暂存环境甚至生产环境。这意味着当您签入测试分支时，构建机器将构建产品，运行构建验证测试并将其部署到您的开发服务器上。当您从测试分支反向集成到主分支时，构建机器构建产品、运行 BVT 并部署在您的暂存测试/验收服务器上。当您集成到发布分支时，构建机器将构建、测试并最终部署到生产环境中。现在是真的，没有多少组织准备好走那么远，让连续构建过程自动部署在实时生产服务器上，我认为这是一种激进的想法。但我说您应该比任何手动测试和部署更信任您的自动化 BVT 和自动化流程。
【讨论】：
Migrator Dot Net 是一款非常棒的数据库版本控制工具。使用迁移后，很难返回手动跟踪脚本和进行数据库比较。
【讨论】：
始终编写脚本来更改架构。将脚本放在升级文件夹中，以便在升级更改时执行脚本以更改每个环境。
【讨论】：
生成脚本向导完全符合我的需要。
【讨论】：
-
您能详细说明一下吗？您是否能够计算两个相似但不同的数据库之间的差异？
-
抱歉，这篇文章已经发布多年了，所以我无法详细说明。当我问这个问题时，我有点绿。我成功使用了 RedGate 工具，但最近我真的很喜欢 RoundHouse，它是 Chuck Norris 框架的一部分。
我个人喜欢在更改特定版本的架构时更新完整的创建脚本以及维护升级脚本。我用过 Red Gate SQL Compare，它是一个非常好的工具，但更喜欢保持脚本的维护。
【讨论】：
最好的办法是将更改实现为一组差异脚本。因此，您的脚本不是删除表并重新创建它，而是作为 ALTER TABLE。
还有一些工具可以帮助您做到这一点。如果您保留原始数据库和新数据库的副本，则可以针对这两个数据库运行一个工具，该工具将生成 SQL，将您从一个版本带到另一个版本。
【讨论】：
我尝试使用RedGate SQL Compare 之类的工具，它会向您显示两个版本之间的“差异”，并实际编写出不同组件的脚本。您还可以养成编写所有数据库修订脚本的习惯，这样您就可以对所做的更改进行审计跟踪，并在准备好部署时以编程方式应用它们。
【讨论】：
-
+1 好答案。我什至没有想到这一点。优秀的产品。
-
比较喜欢 RedGate，虽然还有其他应用程序。尽管如此，要考虑的最大问题是依赖顺序，除了手动之外，RedGate 不会帮助您弄清楚。
-
Red Gate 的 SQL Compare 会按照依赖顺序对脚本进行排序，否则就是 bug！在 SQL Compare 9.5 中，现在有一个新的“迁移”功能，可以让您自定义工具的默认行为。 red-gate.com/MessageBoard/viewtopic.php?t=14113
维护您应用于开发数据库的所有更改脚本的列表，并在部署时将它们应用于生产数据库。
或者，使用可以比较两个架构并提供可以运行的更改脚本的第三方工具。
【讨论】：
-
+1 维护一组更改脚本确实是最好的方法。在您的开发环境中创建它们。将它们部署到测试以确保它们按预期工作，然后将它们部署到生产中。虽然您可以使用 SQL 比较，但我认为最好自己编写更改脚本。如果您坚持使用 GUI (Management Studio)，可以选择让它在您保存更改时自动生成更改脚本。
-
@RobinDay 您如何维护更改脚本列表？我经常使用 GUI 而不是脚本来更改我的数据库。