我最近试了一下(SQL 2008版),我发现它们还可以.好吧,唯一的问题是该向导不够智能,无需先删除所有数据即可更新数据库结构.这就是为什么这些项目没有在实践中使用?
实际上从来没有见过任何人使用它们或者根本没有提过它们.除非你明确地寻找它,否则在博客和论坛中也没什么可看的.
他们怎么了?
我使用属于Visual Studio Database Edition的数据库项目.这是一个很棒的工具.基本上,您可以在创建脚本中定义整个模式,然后将其检入源代码管理中.然后它内置了用于生成差异脚本的工具,顺便说一下,这些脚本不会删除数据.
它还具有数据比较工具,因此您可以比较数据库之间的数据并生成脚本以使数据库相同.
最近的GDR版本增加了一些有趣的功能.这听起来如果你使用他们的内置部署方法,你可以生成一个部署包,当你运行它时将分析目标数据库并仅应用差异.
如果您有Team Studio - Team Suite或Development edition,那么您可以使用Database Edition.
尝试一下,这是数据库开发的一个伟大演变
像Glennular一样,我们使用它们来控制我们的模式和s'procs.
虽然我们有一个相当高级的版本控制结构(CI,自动部署到dev,单击部署到舞台和prod); 我们不包含该结构中的任何DB项目.我们还不相信它.
更新:(用于太空)
我们为公司的职能领域(销售,市场营销等)提供单独的TFS项目.在每个TFS项目中,我们有一个Main和Production文件夹.我们还有一个包含数据库项目的TFS项目和另一个包含通用程序集/可视工作室项目的项目.
发布后,我们从Main转为Production.我们没有一个临时分支,因为我们移动太快而无法处理.对或错,我们的生产力部分取决于我们每周发布的生产水平数量; 错误修复,新功能等
CI在Main分支上设置,以便每次检入都会使Build服务器部署到我们的DEV环境.然后运行单元和Web测试,如果成功完成,构建质量将自动设置为"开发".当有人将构建质量更改为"暂存"时,这会导致之前的"暂存"构建设置为"已拒绝",并导致该构建被推送到我们的临时服务器,同时更新配置文件以指向正确的服务器.(我为此使用了TFS Deployer和PowerShell脚本).
QA会测试我们的登台服务器.一旦他们满意,生产团队就会将构建质量更改为"生产".这会导致构建发送到生产区域,然后手动将其复制到正确的位置.完成后,生产通知开发人员然后将该版本分支到Production文件夹中.QA也会收到通知,然后他会进行一系列生产测试,以确认一切确实按预期工作.
我们设置了报告,以向我们展示生产版本之间存在哪些更改,以便我们了解正在部署的每个签入.这可以防止出现未知数据,例如数据库更改等或其他一些可能破坏的代码.
此外,我们的BA正在通过Team System Web Access跟踪工作项目,并了解这些项目何时投入生产.
虽然我们的DBA正在使用数据库版(GDR),但他们对自动部署的控制水平并没有留下深刻印象.我希望罗萨里奥为产品线带来更好的部署控制; 但在那之前我们有TFS Deployer和powershell.
我们用它们.我们保留所有架构创建/更新脚本和存储过程.主要目的是我们可以将项目连接到SourceSafe或SVN.
它是一种简单的方法来控制SQL脚本版本.
尝试在VS中进行一些SQL测试有点古怪,但是你可以找到解决方法.
更新
我们实际上将它内置到我们的部署脚本中,我们的部署工具通过数据库项目(标记文件夹除外)并运行所有脚本.我们刚刚构建了一个用于运行项目的快速工具.如果有人有其他解决方案来部署数据库项目会有所帮助.