如何使用SSDT和Visual Studio 2012数据库项目正确管理数据库部署？

Question

我正处于研究阶段,试图在现有的小项目上采用2012数据库项目.我是C#开发人员,而不是DBA,所以我对最佳实践并不是特别流利.我一直在搜索谷歌和stackoverflow几个小时,但我仍然不知道如何正确处理一些关键的部署方案.

1)在几个开发周期的过程中,如何管理我的数据库的多个版本？如果我的数据库v3上有客户端,并且我想将它们升级到v8,我该如何管理它？我们目前为每个版本的产品管理手工制作的架构和数据迁移脚本.我们是否还需要单独执行此操作,或者新范例中是否有某些内容支持或替换此内容？

2)如果架构以需要移动数据的方式更改,那么处理此问题的最佳方法是什么？我假设预部署脚本中有一些工作要保留数据,然后Post-Deploy脚本会将其放回正确的位置.这是它的方式还是有更好的东西？

3)对如何最好地使用这些新技术的任何其他建议或指导也非常感谢!

更新:自从我最初提出这个问题以来,我对这个问题的理解有所增加,当我想出一个可行的解决方案时,它并不是我希望的解决方案.这是我的问题的重写:

我遇到的问题纯粹与数据有关.如果我的应用程序版本1上有一个客户端,并且我想将它们升级到我的应用程序的第5版,那么如果他们的数据库没有数据,那么我就没有问题.我只是让SSDT智能地比较模式并一次性迁移数据库.不幸的是,客户有数据,所以它并不那么简单.架构从我的应用程序的版本1更改为版本2到版本3(等)所有影响数据.我目前管理数据的策略要求我为每个版本升级维护一个脚本(1到2,2到3等).这使我无法直接从我的应用程序的版本1转到版本5,因为我没有数据迁移脚本直接在那里.为每个客户端创建自定义升级脚本或管理从每个版本到每个更高版本的升级脚本的前景都是指数级无法管理的.我所希望的是,SSDT能够实现某种策略,使得管理数据方面变得更容易,甚至可能像架构方面那样容易.我最近使用SSDT的经历并没有让我对这种策略存在任何希望,但我希望能找到不同的方法.

Answer 1

我自己一直在研究这个问题,我可以告诉你这并不容易.

首先,要解决JT的回复 - 即使使用SSDT具有的声明性更新机制,也无法解除"版本".SSDT做了一个"相当不错"的工作(如果你知道所有的开关和陷阱)将任何源模式移动到任何目标模式,并且确实这不需要verioning本身,但它不知道如何管理"数据运动"(至少不是我能看到的!).因此,就像DBProj一样,您可以在Pre/Post脚本中使用自己的设备.由于数据运动脚本依赖于已知的开始和结束架构状态,因此无法避免对数据库进行版本控制.因此,"数据运动"脚本必须应用于模式的版本化快照,这意味着您不能随意将数据库从v1更新到v8并期望数据运动脚本v2到v8工作(可能,您不会需要一个v1数据动作脚本).

遗憾的是,我无法在SSDT发布中看到任何允许我以集成方式处理此场景的机制.这意味着你必须添加自己的scafolding.

第一个技巧是跟踪数据库(和SSDT项目)中的版本.我开始在DBProj中使用一个技巧,并把它带到SSDT,经过一些研究后发现其他人也在使用它.您可以将数据库扩展属性应用于数据库本身(称为"BuildVersion"或"AppVersion"或类似的东西),并将版本值应用于它.然后,您可以在SSDT项目中捕获此扩展属性,SSDT会将其添加为脚本(然后您可以检查包含扩展属性的发布选项).然后,我使用SQLCMD变量来标识当前传递中应用的源和目标版本.一旦确定源(项目快照)和目标(即将要更新的目标数据库)之间的版本增量,就可以找到需要应用的所有快照.遗憾的是,从SSDT部署内部做起来很棘手,您可能不得不将其移至构建或部署管道(我们使用TFS自动部署并执行自定义操作).

下一个障碍是保持模式的快照及其关联的数据动作脚本.在这种情况下,它有助于使脚本尽可能地具有幂等性(意味着,您可以重新运行脚本而不会产生任何不良副作用).它有助于拆分可以安全地从必须仅执行一次的脚本重新运行的脚本.我们使用静态参考数据(字典或查找表)做同样的事情 - 换句话说,我们有一个MERGE脚本库(每个表一个),使参考数据保持同步,这些脚本包含在帖子中-deployment脚本(通过SQLCMD:r命令).这里要注意的重要一点是,必须以正确的顺序执行它们,以防这些引用表中的任何一个具有彼此的FK引用.我们按顺序将它们包含在主要的部署后脚本中,这有助于我们创建一个为我们生成这些脚本的工具 - 它还解决了依赖顺序.我们在"版本"结束时运行此生成工具以捕获静态参考数据的当前状态.您的所有其他数据动作脚本基本上都是特殊情况,很可能只是一次性使用.在这种情况下,您可以执行以下两种操作之一:您可以对db build/app版本使用IF语句,也可以在创建每个快照包后清除1次脚本.

有助于记住SSDT将禁用FK检查约束,并且仅在部署后脚本运行后重新启用它们.这使您有机会填充新的非空字段,例如(顺便说一下,您必须启用该选项为非空列生成临时"智能"默认值才能使其工作).但是,仅对因模式更改而重新创建SSDT的表禁用FK检查约束.对于其他情况,您有责任确保数据运动脚本以正确的顺序运行,以避免检查约束投诉(或者您在脚本中手动禁用/重新启用它们).

DACPAC可以为您提供帮助,因为DACPAC本质上是一个快照.它将包含几个描述模式的XML文件(类似于项目的构建输出),但在创建它时会及时冻结.然后,您可以使用SQLPACKAGE.EXE或部署提供程序来发布该程序包快照.我还没有弄清楚如何使用DACPAC版本,因为它更依赖于"注册"数据应用程序,所以我们坚持使用我们自己的版本控制方案,但我们确实将自己的版本信息放入DACPAC文件名.

我希望我能提供一个更具决定性和实用性的例子,但我们仍然在这里解决问题.

关于SSDT真的很糟糕的一点是,与DBProj不同,它目前无法扩展.虽然它在很多不同的事情上比DBProj做得好得多,但你不能覆盖它的默认行为,除非你能找到解决问题的前/后脚本中的一些方法.我们现在试图解决的一个问题是,当你有数千万条记录时,重新创建更新表(CCDR)的默认方法确实很糟糕.

-UPDATE:我有一段时间没见过这篇文章,但显然最近一直很活跃,所以我想我会添加几个重要的注释:如果你使用的是VS2012,那么2013年6月发布的SSDT现在有一个数据内置比较工具,并提供可扩展性点 - 也就是说,您现在可以为项目包含Build Contributors和Deployment Plan Modifiers.

Answer 2

我还没有真正找到关于这个主题的更多有用的信息,但我花了一些时间来了解工具,修修补补和玩耍,我想我已经想出了一些可接受的问题答案.这些不一定是最好的答案.我仍然不知道是否有其他机制或最佳实践来更好地支持这些场景,但这是我提出的:

给定版本数据库的Pre-and Deploy脚本仅用于迁移先前版本的数据.在每个开发周期开始时,脚本都会被清理掉,随着开发的进行,它们将被充实,无论使用什么样的SQL来安全地将数据从先前版本迁移到新版本.这里的一个例外是数据库中的静态数据.此数据在设计时已知,并以T-SQL MERGE语句的形式在Post-Deploy脚本中保持永久存在.这有助于将任何版本的数据库部署到仅具有最新发布脚本的新环境.在每个开发周期结束时,将从先前版本生成发布脚本到新版本.此脚本将包括生成的sql以迁移架构和手工制作的部署脚本.是的,我知道发布工具可以直接用于数据库,但这对我们的客户来说不是一个好选择.我也知道dacpac文件,但我不确定如何使用它们.生成的发布脚本似乎是我所知道的生产升级的最佳选择.

所以回答我的情景:

1)要将数据库从v3升级到v8,我必须为v4执行生成的发布脚本,然后执行v5,然后执行v6等.这与我们现在的执行方式非常相似.这很好理解,数据库项目似乎使创建/维护这些脚本变得更加容易.

2)当架构从底层数据发生变化时,部署前和部署脚本用于将数据迁移到新版本所需的位置.受影响的数据基本上在预部署脚本中备份,并在Post-Deploy脚本中重新放置.

3)我仍然在寻找有关如何在这些场景和其他场景中最好地使用这些工具的建议.如果我在这里弄错了,或者我还应该知道其他任何问题,请告诉我!谢谢!