我正处于研究阶段，试图在现有的小型项目上采用2012年数据库项目。我是C＃开发人员，而不是DBA，所以我不太熟练使用最佳实践。我已经搜索了google几个小时，但是我仍然不知道如何正确处理一些关键的部署方案。
1）在几个开发周期中，如何管理数据库的多个版本？如果我在数据库的v3上有一个客户端，并且想将其升级到v8，该如何管理？当前，我们为产品的每个版本管理手工制作的架构和数据迁移脚本。我们是否仍需要单独执行此操作，或者新范式中是否有支持或替换此操作的内容？
2）如果架构以需要移动数据的方式进行更改，那么处理此问题的最佳方法是什么？我假设在部署前脚本中进行了一些工作来保留数据，然后在部署后脚本中将其放回正确的位置。是这样吗，还是有更好的办法？
3）对于如何最好地使用这些新技术的任何其他建议或指导，也将深表感谢！
更新： 自从我最初提出这个问题以来，我对该问题的理解已有所提高，而当我想出一个可行的解决方案时，这并不是我所希望的解决方案。这是我的问题的改写：
我遇到的问题纯粹是与数据有关的。如果我在我的应用程序的版本1上有一个客户端，并且想要将其升级到我的应用程序的版本5，则在他们的数据库没有数据的情况下，我将没有问题。我只是让SSDT明智地比较模式并一次迁移数据库。不幸的是，客户拥有数据，所以它不是那么简单。从应用程序的版本1到版本2到版本3（等）的架构更改都会影响数据。我当前的数据管理策略要求我为每个版本升级（1到2、2到3等）维护一个脚本。这使我无法从应用程序的版本1直接转到版本5，因为我没有数据迁移脚本可以直接到达那里。为每个客户创建自定义升级脚本或管理从每个版本到每个更高版本的升级脚本的前景都难以管理。我希望有一种SSDT支持的策略可以使事物的数据方面的管理更加容易，甚至与事物的架构方面一样容易。我最近在SSDT方面的经验并没有使我对这种策略的存在抱有任何希望，但我希望能有所不同。
我自己一直在努力，我可以告诉你这并不容易。
首先，要解决JT的答复- 即使使用SSDT具有声明性的更新机制，也不能忽略“版本”。SSDT所做的“相当不错”的工作（只要您知道所有的开关和陷阱），就可以将任何源模式迁移到任何目标模式，这确实是不需要验证的，但是它不知道如何管理“数据运动”（至少我看不到！）。因此，就像DBProj一样，您可以在Pre / Post脚本中留给自己的设备。因为数据运动脚本取决于已知的开始和结束模式状态，所以您无法避免对数据库进行版本控制。因此，“数据移动”脚本必须应用于架构的版本快照，这意味着您不能将数据库从v1任意更新为v8，并且不能期望数据移动脚本v2至v8可以正常工作（大概是，您不会
可悲的是，我在SSDT发布中看不到任何机制可以让我以集成方式处理这种情况。这意味着您必须添加自己的脚手架。
第一个技巧是跟踪数据库（和SSDT项目）中的版本。我开始在DBProj中使用一个技巧，并将其带到SSDT，经过一些研究，结果发现其他人也正在使用此技巧。您可以将数据库扩展属性应用于数据库本身（称为“ BuildVersion”或“ AppVersion”或类似名称），然后将版本值应用于数据库。然后，您可以在SSDT项目本身中捕获此扩展属性，然后SSDT将其添加为脚本（然后可以检查包含扩展属性的发布选项）。然后，我使用SQLCMD变量来标识当前过程中应用的源版本和目标版本。一旦确定了源（项目快照）和目标（即将更新的目标数据库）之间的版本差异，就可以找到所有需要应用的快照。 在 SSDT部署中，您可能必须将其移至构建或部署管道中（我们使用TFS自动部署，并具有自定义操作来执行此操作）。
下一个障碍是保持架构快照及其关联的数据运动脚本。在这种情况下，有助于使脚本尽可能地幂等（这意味着您可以重新运行脚本而不会产生任何不良影响）。它有助于将可以安全地重新运行的脚本从仅必须执行一次的脚本中分离出来。我们对静态参考数据（字典或查找表）执行相同的操作- 换句话说，我们有一个MERGE脚本库（每个表一个），这些脚本使参考数据保持同步，并且这些脚本也包含在帖子中- deployment脚本（通过SQLCMD：r命令）。这里要注意的重要一点是，您 必须 如果这些引用表中的任何一个具有彼此的FK引用，请以正确的顺序执行它们。我们将它们按顺序包含在主要的部署后脚本中，这有助于我们创建一个可以为我们生成这些脚本的工具- 它还可以解决依赖关系的顺序。我们在“版本”结束时运行此生成工具，以捕获静态参考数据的当前状态。您所有其他的数据运动脚本基本上都将是特殊情况，并且很可能仅是一次性使用。在这种情况下，您可以执行以下两项操作之一：您可以对db build / app版本使用IF语句，或者可以在创建每个快照程序包后清除1次脚本。
请记住，SSDT将禁用FK检查约束，并且仅在部署后脚本运行后才重新启用它们。例如，这使您有机会填充新的非null字段（顺便说一句，您必须启用该选项才能为非null列生成临时的“智能”默认值，以使此工作有效）。但是，由于架构更改，仅对SSDT正在重新创建的表禁用FK检查约束。对于其他情况，您有责任确保数据运动脚本以正确的顺序运行，以避免检查约束投诉（或者您可以在脚本中手动禁用/重新启用它们）。
DACPAC可以为您提供帮助，因为DACPAC本质上是快照。它将包含几个描述模式的XML文件（类似于项目的生成输出），但是在创建时会被冻结。然后，您可以使用SQLPACKAGE.EXE或部署提供程序来发布该程序包快照。我还没有弄清楚如何使用DACPAC版本控制，因为它与“已注册的”数据应用程序联系更紧密，因此我们坚持使用自己的版本控制方案，但是我们确实将自己的版本信息放入DACPAC文件名中。
我希望我能提供一个更具决定性和更具启发性的示例，但我们仍然在这里研究这些问题。
关于SSDT真正令人讨厌的一件事是，与DBProj不同，它目前不可扩展。尽管它在许多方面都比DBProj更好，但您不能覆盖其默认行为，除非您可以在解决问题的前后脚本中找到一些方法。我们现在要解决的问题之一是，当您拥有数千万条记录时，重新创建更新表（CCDR）的默认方法确实很麻烦。
-更新：我已经有一段时间没看过这篇文章了，但是显然它最近很活跃，所以我想我要补充一些重要的注意事项：如果您使用的是VS2012，2013年6月发行的SSDT现在有一个数据内置比较工具，还提供了可扩展性点-也就是说，您现在可以包括该项目的“构建贡献者”和“部署计划修改者”。
