将数据库更新部署到生产数据库的最新技术是什么？

Question

我工作的每个商店都有自己的拼凑，偶然，难以理解和维护不良的方法来更新生产数据库。

我从未见过这样做的一致方法。

因此，在最新版本的SQL Server中，更新架构更改以及将数据从开发或测试服务器迁移到生产服务器的最佳做法是什么？

是否有第三方工具可以轻松处理这个问题？

我认为终极工具能够

• 检测两个DB之间的模式更改并生成DDL以将其更新为另一个。
• 包括具有执行自定义数据迁移步骤的自定义代码的功能
• 允许版本控制，以便v1 db可以一直更新到v99数据库，按顺序运行所有脚本和迁移步骤。

Answer 1

我用过的三件事是：

对于架构

Visual Studio数据库项目。咩。他们没事，但你还是要自己做很多工作。

Red Gate的SQL Compare和整个SQL Toolbelt。他们非常努力地制作了可以控制版本的东西。在实践中，我发现数据库中你经常试图从版本时间线中的A点到达B点。对于二进制文件，你经常只是用点B来破坏它（我知道的过于简单化，但通常都是真的）。 / p>

http://www.red-gate.com/

如果您的系统很小并且可能仍然很小，那么xSQL是一个很好的起点：

http://www.xsqlsoftware.com/LiteEdition.aspx

我不为那些为这些人工作或从这些人那里得到任何钱的人工作或认识。告诉你我过去做过什么。

数据

Red Gate有SQL数据比较。

但是，如果你想要“免费”（或包含在SQL Server中） 我实际上只是使用BCP并编写了一个注入和提取数据的小系统，取得了很大的成功。通常当我发现自己这样做时，我会问自己，“为什么？如果我要更改数据，这是否意味着我真的在改变配置？我可以在这里使用不同的方法吗？”但有时你不能（也许它是一个遗留系统，原始开发人员认为数据库适用于所有东西）。

BCP提取的问题是它们不能很好地控制版本。我曾经使用过一些技巧，比如在字符模式下提取并在提取查询中填充订单，尝试按顺序拉出行，使它们更适合版本控制。

Answer 2

对于小型项目，我使用RedGate来管理架构和数据迁移，并取得了很大成功。在大多数情况下非常容易使用。

对于架构和数据更改的大型企业系统，通常将所有SQL脚本保存为文本文件并运行它们。我们还包括一个Rollback脚本，可以在迁移过程中运行出错。在UAT服务器上运行，然后在Test / staging / pre prod server上运行，然后在Production上运行。保存所有这些文件及其回滚脚本的副本应该允许您从数据库的多个版本移动。

还有http://code.google.com/p/migratordotnet/如果你使用.NET它允许你在CODE中定义这些脚本。如果要以自动方式跨多个DB进行部署，则非常有用。可以轻松地将我的数据库设置为版本23.或者将我的数据库恢复为版本5.等适用于模式和数据，但我只会将它用于几行数据。

Answer 3

首先，你必须认为场景之间的要求差不多很多：

1. 客户在Costco购买产品的v1，并将其安装在家庭办公室或小型企业中。当v2发布时，客户购买一盒产品并将其安装在新计算机上。它从v1安装导出数据并将其导入v2安装。即使幕后v1和v2都使用SQL Express实例，也没有支持的升级。不期望部署的数据库上的模式更改（隐藏数据库，非技术用户），并且绝对不受支持。支持的唯一“升级”路径是显式导出/导入，可能使用XML文件或类似的东西。

2. 企业通过支持合同购买产品v1。它将其安装在其部门SQL Server实例上，购买的产品和通过更多集成服务，报告等访问数据。当v2发布时，客户运行规定的升级过程，如果遇到问题，它会调用产品供应商客户支持热线，该产品线会引导客户完成部署的一些特定步骤。预期并经常支持数据库模式自定义，包括升级方案，但模式更改由客户完成（在v2设计时未知）。

3. Web启动具有支持该站点的数据库。开发人员对其个人实例进行更改并签入更改。具有连续集成的自动构建部署获取更改并将其部署到测试实例，并运行构建验证测试。主分支构建可以随时部署到生产中。生产是 一个支持该站点的数据库。生产数据库的结构被记录并100％理解，生产数据库模式的每一次更改都通过构建系统和QA过程进行。另一方面，这是大多数提出问题的SO用户的场景，减去“100％记录和理解”的部分。我举了WWW支持网站的例子，但是实际上可以解决问题。它的要点是只有一个生产数据库（它可能包含HA / DR副本，它可能包含多个实际的SQL Server数据库），并且是必须升级的唯一数据库

4. 成功网络启动。与上述相同，但生产数据库有5TB的数据，5分钟的停机时间是CNN的头条新闻。架构更改可能涉及设置副本并将数据复制到具有连续更新的新架构中，然后将操作联机切换到副本。模式更改由MCM专家设计，部署模式更改可能是一个为期数周的过程。

我可以继续了解更多场景。关键在于，每种情况的要求都是如此巨大的不同，没有“最先进的”可以回答所有这些情况。使用vsdbcmd或SQL Compare等架构差异部署工具，某些方案完全可以。使用显式versioning scripts可以更好地面对其他情况。其他可能有这样的特定要求（例如0停机时间），每个升级都是一个项目，并且必须专门定制。

在所有情况下都有一点是清楚的：如果您的商店威胁开发数据库 MDF文件 *作为“来源”并使用管理工具对其进行更改，那么始终< / strong>一个主要的#fail。应该将所有更改显式捕获为某种源控件工件，这就是我支持大多数显式版本脚本的原因，如Version Control and your Database中所述。但我认为VSDB项目支持编译时模式验证及其重构模式对象的简易性是一个非常强大的命题和VSDB模式比较部署可能没问题。

必须解决的另一个重要问题是来自EF或LinqToSql等工具的代码优先模式建模。它可以很好地部署v1，但在任何后续版本中都会失败。我强烈反对这些方法。

但总结并简要回答：就像今天一样，现有技术很糟糕。

Answer 4

在Red Gate，我们建议根据您的要求以及您需要流程的正式程度中的两种方法之一。如果您有一个开发数据库并且只想将更改推送到生产环境，则SQL Compare是该工作的工具。可以使用模式快照实现版本控制级别。

但是，如果您希望获得完整的源代码管理权益，例如团队协作，沙盒环境，审计跟踪，合规性，历史记录，回滚等，则应考虑SQL Source Control。这将开发数据库链接到Team Foundation Server或Subversion。