有人在Visual Studio中使用“数据库项目”吗？

Question

我最近尝试过（SQL 2008版），我发现它们还可以。好吧，唯一的问题是该向导不够智能，无需先删除所有数据即可更新数据库结构。这就是为什么这些项目没有在实践中使用？

实际上从未见过任何人使用它们或者根本没有提及它们。除非你明确地寻找它，否则在博客和论坛中也没什么可看的。

他们有什么问题？

Answer 1

我使用属于Visual Studio Database Edition的数据库项目。这是一个很棒的工具。基本上，您可以在创建脚本中定义整个模式，然后将其检入源代码管理中。然后它内置了用于生成差异脚本的工具，顺便说一下，这些脚本不会删除数据。

它还有数据比较工具，因此您可以比较数据库之间的数据并生成脚本以使数据库相同。

最近的GDR版本增加了一些有趣的功能。这听起来如果你使用他们的内置部署方法，你可以生成一个部署包，当你运行它时将分析目标数据库并仅应用差异。

如果您有Team Studio - Team Suite或Development edition，那么您可以使用Database Edition。

试一试，这是数据库开发的一个伟大进步

Answer 2

与Glennular一样，我们使用它们来控制我们的架构和s'procs。

虽然我们有一个相当高级的版本控制结构（CI，自动部署到开发，单击部署到舞台和prod）;我们不包含该结构中的任何DB项目。我们还不相信它。

更新：（适用于空间外）

我们为公司的职能领域（销售，市场营销等）提供单独的TFS项目。在每个TFS项目中，我们有一个Main和Production文件夹。我们还有一个包含数据库项目的TFS项目和另一个包含通用程序集/可视工作室项目的项目。

发布后，我们从Main转为Production。我们没有一个临时分支，因为我们移动太快而无法处理。对或错，我们的生产力部分取决于我们每周发布的生产水平数量;错误修复，新功能等。

在主分支上设置CI，以便每次检入都会使Build服务器部署到我们的DEV环境。然后运行单元和Web测试，如果成功完成，构建质量将自动设置为“开发”。当有人将构建质量更改为“暂存”时，这会导致之前的“暂存”构建设置为“已拒绝”，并导致该构建被推送到我们的临时服务器，同时更新配置文件以指向正确的服务器。 （我为此使用了TFS Deployer和PowerShell脚本）。

QA会测试我们的登台服务器。一旦他们满意，生产团队就会将构建质量更改为“生产”。这会导致构建发送到生产区域，然后手动将其复制到正确的位置。完成后，生产通知开发人员然后将该版本分支到Production文件夹中。还会通知质量保证人员然后进行一系列生产测试，以确认一切确实按预期工作。

我们设置了报告，以向我们展示生产版本之间存在哪些更改，以便我们了解正在部署的每个签入。这可以防止出现未知数据，例如数据库更改等或其他一些可能破坏的代码。

此外，我们的BA正在通过Team System Web Access跟踪工作项目，并知道这些项目何时投入生产。

尽管我们的DBA正在使用数据库版（GDR），但他们对自动部署的控制水平并未留下深刻印象。我希望罗萨里奥为产品线带来更好的部署控制;但在那之前我们有TFS Deployer和powershell。

Answer 3

我们使用它们。我们保留所有架构创建/更新脚本和存储过程。主要目的是我们可以将项目连接到SourceSafe或SVN。

这是一种简单的方法来控制SQL脚本版本。

尝试在VS中进行一些SQL测试有点古怪，但是你可以找到解决方法。

更新

我们实际上将它内置到我们的部署脚本中，我们的部署工具通过数据库项目（标记文件夹除外）并运行所有脚本。我们刚刚构建了一个用于运行项目的快速工具。如果有人有其他解决方案来部署有用的数据库项目。

Answer 4

我们使用数据库项目为我们的SQL脚本提供版本控制。我们也喜欢使用Visual Studio环境来编辑SQL;对于我们的一些新开发人员而言，它比查询分析器更容易使用。

Answer 5

我在一些付费项目中使用它们，我认为它是一个很棒的工具。多数民众赞成说，我看到了一些问题。

1. 如果db项目文件夹中的.dat文件与数据库的临时实例不同步，则架构比较将提供不准确的结果。不确定如何发生这种情况，如果事情看起来不对，请仔细检查架构并彻底清除你的.dat文件（在关闭解决方案之后）。

2. 如果你有20多个数据库，他们互相引用并使用循环引用......它会受到伤害。我还没想出如何让它扩展到那种情况。 GDR 2似乎提供了一些承诺。