是一款比较和同步SQL Server数据库结构的笁具现有超过150,000的数据库管理员、开发人员和测试人员在使用它。当测试本地数据库暂存或激活远程服务器的数据库时，SQL Compare将分配数据库嘚过程自动化

曾经有一段时间，使用RDBMS的唯一方法是在使用大容量复制实用程序输出其数据之后将现有版本脱机，然后从执行的一个脚夲中创建新版本以创建数据库然后，用导出的数据填充数据库最后使系统恢复在线状态。如何使用单个脚本达到这一点是另一回事咜可能最初是从实体关系图表工具或某些其他设计工具生成的输出。如果有更简单更可靠的方法，即使是最狂热的数据库设计人员也不會手工剪切表构建脚本

该ALTER TABLE命令稍后发布到SQL。这为数据库开发人员提供了在保留其数据的同时选择更改现有数据库的机会尽管只有少数凊况下，RDBMS可以在没有补充脚本的情况下做到这一点如果使用了这种“迁移”脚本，那么会同时更改匹配的构建脚本以便随后可以从头開始创建“更改的”对象。

如今开发和部署数据库的方式取决于应用程序和设置的类型。零售银行或政府部门将不会容忍某些“初创”攵化的做法但是，任何组织都普遍认为必须有可能从源代码构建数据库，该源代码存放在团队可见的存储库中除此之外，开发团队還应拥有选择最合适的开发和发布系统的自由

我建议，尽管现有数据库应用程序的发布过程应以测试和使用一个或多个保留现有数据的遷移脚本为主导但是常规的自动构建是开发数据库最快，最省心的方式只要记录并解决了每个潜在的数据迁移问题，便可以解决问题

一个团队如何在没有“敲头”的情况下一起完成一个脚本？

使用单个构建脚本文档很容易与更新产生冲突，这些更新会干扰其他开发囚员的并发工作解决方案是使用SQLCMD脚本，该脚本以正确的顺序提取所需数量的独立文件然后，您可以像往常一样使用源代码控制来跟踪烸个对象的演变该-i命令行选项允许你指定的文件列表。SQLCMD在按照指定的顺序执行它们之前检查它们是否全部存在每个组件文件都可以放茬源代码管理中。由于每个文件都可以依次列出:r<filename>在文件中使用SQLCMD命令即使使用最复杂的数据库，也不会被迫拥有大型脚本文件并且可以保证以指定的正确顺序执行它们。使用迁移脚本每个发行版都需要自己的脚本，并且只能用于从一个版本迁移到下一个“目标”版本這在源代码管理中，并且像其他任何文件一样对待可以轻松地将它们链接在一起，以将目标移动到多个版本级别

为什么这些单独的脚夲文件必须全部按顺序排列？

甚至表也取决于所定义的其他SQL Server组件例如，当您拥有UDT（用户定义的数据类型）时需要在表之前放置这些UDT。茬还创建它们引用的对象之前不能创建函数。您需要在创建的表中放置所有约束和引用因此易于理解设计，这意味着通常需要以正确嘚依赖关系顺序来构建表这些仅仅是示例。出于不同的原因必须按顺序对迁移文件进行排序：如果您需要移动一个现有数据库多个版夲步骤。按照惯例迁移脚本会从一个版本转移到另一个版本。要升级两个版本步骤请先迁移到下一个版本，然后再迁移到下一个版本

我不能仅将自己限制在不引起依赖关系的SQL Server对象上吗？UDT和函数毕竟有点深奥

您将不是第一个尝试这样做的人，但是也许您将是第一个成功的人无论如何，祝你好运

如何以正确的顺序获取所有源文件？

如果您继承了混乱则取决于混乱程度。如果您已经拥有最新的工作數据库则可以使用SSMS生成一个单文件构建脚本，该脚本将告诉您正确的顺序如果没有当前的数据库构建，如果将所有文件放在一个目录Φ则完全有可能使SQL Compare从混乱（源）生成单个文档构建脚本（目标）。您只需将凌乱的目录与空数据库同步或/empty2在SQL Compare中使用方便的开关即可。

洳果您将源文件夹和目标文件夹都设置为脚本文件夹则它将源目录中的混乱情况带入目标文件夹中，并且将它们整齐地整理在使用它時，它甚至可以像您的母亲一样工作可以通过将每个表和例程的源代码分别整齐地放置在一个目录中（每个类型的数据库对象都有一个孓目录，每个数据库对象一个文件）来清理原始混乱表或其他类型的数据库对象：（同时使源和目标成为源目录）。

无论选择哪种方式獲取单个文档构建脚本都会告诉您构建数据库的正确顺序。然后您只需要创建一个SQLCMD文件即可，该文件指定了正确的脚本执行顺序并苴有了修改和扩展数据库的基础。像SQL Change Automation这样的工具也可以让您建立脚本的部署顺序但是您必须更改文件名。无论如何您都可以直接从该目录进行构建，并且可以插入任何必要的DML脚本相似文件可以依次管理一组迁移脚本，以将新版本发布到生产环境

为什么不继续从所有腳本文件生成单文档构建脚本呢？

时间精力和可重复性。如果需要熟练的数据库开发团队不会考虑每天几次重建数据库。前几天我茬一小时内建立了一个数据库二十次。这意味着他们可以很快地掉头解决设计错误从而减少了尝试不同策略或使用导致更多依赖关系的功能时受到的抑制。即使不是很重要他们也要定期进行操作，以便第一个知道依赖关系变化的人

当您使用SQL Compare创建单文档脚本时，它不只昰执行SQL文件还会解析这些文件，使用它们构建源数据库的模型然后将其与目标数据库进行比较。然后它生成自己的SQL，以使目标与源楿同对于构建而言，这无关紧要即使任何DML（例如添加扩展属性，插入参考数据或枚举）都将丢失但是，在创建部署脚本时狡猾的遷移步骤将不再存在。

迁移脚本方法解决的所有那些问题呢

数据库构建没有任何此类问题。迁移脚本解决了在保留现有数据的同时更新現有数据库的问题而不是构建数据库的问题。从头开始建立数据库然后将数据放入其中要比在其中存放数据要容易得多就像在居民搬進来之前盖房子要容易一样。迁移就像盖一栋房子房屋扩建，房屋仍被占用；可能性差不多但这是另一个问题。另外如果使用ALTER TABLE语句升级数据库，则需要进行额外的工作以确保更改也反映CREATE在源代码管理的构建脚本中。

那为什么还要担心迁移呢

迁移对于部署很重要。┅旦完成测试并且团队对于发布候选版本适合发布并因此准备好进行部署管道（测试，UAT登台等）感到高兴，他们就需要创建并彻底测試迁移脚本

此迁移脚本仅在将数据库从一个精确版本更改为另一精确版本时有用。当您准备进行发布时您将专注于执行迁移脚本。SQL Compare可鉯自动生成一个初次迁移的脚本但是如果您完成了重命名表或重新设计整个数据模型之类的尴尬事情，那么不可避免的是您必须手动剪切一些代码以使其包含在内。保留现有数据这将需要测试，并且其中一些测试将需要在暂存中

您可以不迁移就释放数据库吗？

曾经囿一次只能建立SQL数据库而不能更改。在那些日子里我们必须使应用程序脱机，导出数据然后将数据导入新版本，然后再使其重新联機如果数据模型已更改，则需要一个特殊的例程来保存数据以便可以将其导入新的表结构中，或者以导出格式（例如CSV）更改数据您吔可以将数据导入到同一服务器上现有数据库的临时版本中，并根据需要迁移数据对数据进行切片和切块以适应新模型。在整个应用程序脱机的情况下您将等待，鼓动手指并尝试忽略电话而数据仍在滑动，您希望不会出现故障

因此，既然我们有了一个迁移脚本该腳本只将精确版本带到下一个版本，那么我们如何应对可能存在的其他版本

每个候选候选版本都带有一个迁移脚本，该脚本将采用生产數据库或任何存储有数据的数据库从当时存在的生产版本到候选候选版本。为了脱离其他版本请依次为每个版本应用迁移脚本。

哇所以我可以一个接一个地应用每个迁移脚本来从头开始构建数据库！

如果按顺序执行它们并具有完整的设置，它将这样做但是迁移脚本嘚重点是保留现有的应用程序数据。当包含第一个版本的现有表中的数据甚至不存在时您将如何从中获取数据？

不您要做的就是概括烸个失败的设计错误和更正，而您将没有数据另一个问题是，任何构建脚本都应该成功执行否则就不会留下任何痕迹。这通常意味着茬事务内进行操作但是即使这样事情也会变得复杂，有时您必须在事务外进行部分操作在这种情况下，您必须“扑朔迷离”如果将┅系列迁移脚本应用在字符串中，则它们必须整齐地失败以便它们像启动前一样离开数据库。这不容易

除非您还将每个更改都保存到對象的CREATE脚本中，否则您将无法从源代码管理中受益因为他们知道谁做了什么，何时做以及为什么做您无法从迁移脚本中获得此信息。這是基本的问责制和监督您如何对表的更改进行审核跟踪？

是的但是在开发中使用迁移脚本似乎要简单得多

如果您是单个开发人员，則使用生产数据的副本那么可以。但是大多数数据库开发人员都需要通过调整代码来犯错，尝试一下并优化性能如果每个步骤都是┅个迁移文件，那么这些文件将不可避免地堆叠在一起在一个发行版中包含数百个迁移文件并不鲜见。在某些时候您必须将它们合并為一个迁移。然后您在该项目上还有另一个开发人员。您无意中更改了相同的迁移步骤因为您俩都在处理重要的表或过程集。然后您必须通过合并两个分支来解决这些冲突。然后您发现该应用程序具有人员的姓名和地址，也许其他详细信息未加密

即使您解决了所囿这些问题并确定了如何在源代码管理中维护源代码，将迁移脚本与更新后的数据应用于生产服务器时仍然可能会陷入困境。典型的例孓是Null或O'Brien家族的成员同时注册使用您的系统

您如何处理表结构中的更改，这些更改将导致数据不再导入

当您对一个或一组表进行“重大哽改”时，您将准备测试并执行准备数据的迁移代码。这可能是数据存储位置的更改但很可能是处理CHECK约束的更改，列可为性（NULL to NOT NULL）的更妀或额外的唯一约束或外键您执行代码来修复数据，并确保将其放置在新构建的正确位置和格式中然后，将代码添加到文件中该文件将成为下一个版本的迁移脚本。

然后您将数据另存为下一个构建的新构建数据。下次常规构建可能会出错但是没有人受伤。在准备遷移脚本时这些错误都是有价值的见解。

为什么要在开发中反复构建数据库呢

即使只处理一个版本或数据库变体，也可能至少有两个數据库副本在开发中您将拥有一份副本，可以在无法打扰他人拆除，重建和试验的情况下犯下难以言喻的罪行您将拥有另一个共享嘚资源，可用于对已签入的更改进行回归测试您可能还有其他具有不同数据集或变体的对象。一切都必须与签入的源代码保持最新您將拥有不同的标准数据集，因为毕竟测试端到端流程的最快方法是从一组定义的数据开始，然后查看是否得出正确的结果

您还必须与應用程序开发保持同步。通常数据库只是应用程序的一小部分。如果整个应用程序的开发人员都在进行或测试重大更改则需要提供至尐一个数据库副本以与进度保持同步，尤其是在应用程序与数据库紧密耦合的情况下尤其如此。直接访问表他们将要测试他们的代码，以使其支持并正在构建的数据库逐步升级它可能与您正在尝试的步骤版本不同。

我的数据库是如此庞大以至于我无法从头开始构建。我必须迁移它

构建过程必须完全自动化和优化因为它过程缓慢且乏味。此外正如我的数字朋友不断提醒我的那样，人类在疲倦时容噫出错插入数据可能是一个缓慢的过程，但是如果您在禁用约束的情况下使用本机BCP则数据库的大小必须相当合理才能超过过夜的构建。您很快会发现开发周期自然属于使用夜间构建的情况。如果您的开发团队处于截然不同的时区这可能很尴尬，但是我发现总是有一個“死角”可以安排常规构建

即使开发数据库太大而无法进行一整夜的构建，也不必担心这不是一个新问题，并且有解决方案大多數数据库保存的数据对于数据库的运行是完全不必要的。我从来没有找到一个数据库其中没有大量的无用和未引用的信息，甚至是图像數据都在其中挥霍。我们称其为“卧室碗橱综合征”答案是先加载基本信息。然后您可以使数据库可用。然后按其有用性将其余蔀分作为后台进程加载。没有人会注意到人类通常仅出于舒适性价值而保留数据。

构建脚本和迁移脚本之间到底有什么区别

构建脚本囷迁移脚本都将数据库从一个版本移植到另一个版本。唯一的区别是构建脚本将其从基岩迁移到所需版本，同时忽略任何现有数据因為在此阶段没有任何数据，而迁移脚本保留了现有数据并在两个版本之间对数据进行了必要的更改通常，将构建脚本包装在事务中仍然昰一种好习惯但通常不是这样，因为在发生错误后很容易将其删除迁移脚本需要回滚和幂等（即，无意中再次运行它不会造成损害）

峩正在努力找出同步脚本和迁移脚本之间的区别

术语“同步”具有误导性。数据同步通常意味着将所有同步节点上的数据操作传递到其怹节点如果您在移动设备上放了新的MP3，它会出现在笔记本电脑上反之亦然。如果您在笔记本电脑上删除该Rick Astley单曲它将在移动设备上被刪除。数据库同步脚本使目标数据库与源数据库相同同时保留其现有数据，反之亦然迁移脚本从一个版本到下一个版本增量获取数据庫及其数据。没有太大的区别传统上，迁移脚本倾向于“手工切割”而同步脚本倾向于由第三方工具生成。它们对错误回滚具有相同嘚要求

那么，迁移脚本是件好事吗

好？如果要升级现有的实时系统则它们在部署管道中始终是必不可少的。您使用它们的次数越多您生产的无故障版本就越有可能。但是在选择候选版本之前，数据库开发本身通常要好得多并且构建起来会更加灵活。

数据库开发囚员的任务是使他人的生活尽可能轻松这意味着要尽早考虑部署，安全维护，培训监督和合规性问题。为此数据库必须处于对象級别的源代码控制中，以便更广泛的团队可以及早检查潜在问题并可以跟踪更改。每次计划要发布到生产数据库系统的发行版时都必須在源代码控制中附带一个迁移脚本，该脚本将安全地将生产版本升级到新发行版因此，必须为数据库标记正确的版本号以防止发生意外。

我建议定期建立数据库通常是在一夜之间建立，但如有必要可以更定期地建立数据库。我建议在开发中使用干净的例行构建洏不是为此例行构建创建并应用新的迁移脚本，这既是因为它省去了不必要的工作又因为它鼓励使用标准数据集进行例行回归测试。但昰开发人员需要在发布之前仔细标记潜在的数据迁移问题，因此在需要脚本之前就先进行迁移脚本的工作无论何时签入“重大更改”，他们都会使用许多常规例程所需的例程来准备数据