Visual studio 任何人使用；“数据库项目”；在VisualStudio中？

我最近尝试了一下（SQL2008版本），我发现它们非常好。唯一的问题是向导不够智能，无法在不删除所有数据的情况下更新数据库结构。这就是为什么这些项目没有在实践中使用

事实上从未见过有人使用它们或提及它们。在博客和论坛上也看不到任何东西，除非你明确地寻找它

---

它们怎么了？

我使用的数据库项目是Visual Studio数据库版的一部分。这是一个很棒的工具。基本上，您可以在创建脚本中定义整个模式，然后将脚本签入源代码管理。然后，它有内置的工具来生成不同的脚本，顺便说一句，这些脚本不会删除数据

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

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

如果您有TeamStudio-TeamSuite或DevelopmentEdition，那么您可以使用数据库版

---

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

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

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

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

更新

---

实际上，我们已经将它内置到部署脚本中，部署工具将通过DB项目（标记文件夹除外）运行所有脚本。我们刚刚建立了一个快速的工具来运行这个项目。如果有人有其他解决方案来部署DB项目，那会很有帮助。

像Glennular一样，我们正在使用它们来控制我们的模式和进程的版本

尽管我们有一个相当高级的版本控制结构（CI、自动部署到开发人员、单击部署到阶段和产品）；我们不在该结构中包含任何DB项目。我们只是还不相信它

更新：（适用于外太空）

我们为公司的职能领域（销售、营销等）制定了单独的TFS项目。在每个TFS项目中，我们都有一个主文件夹和生产文件夹。我们还有一个TFS项目，其中包含数据库项目，另一个包含公共程序集/VisualStudio项目

发布后，我们将从主要分支机构转到生产部门。我们没有临时分支机构，因为我们行动太快，无法处理这一问题。无论是对是错，我们的生产力部分是通过我们每周发布的生产级版本数量来衡量的；错误修复、新功能等

CI设置在主分支上，这样每次签入都会导致构建服务器部署到我们的开发环境中。然后运行单元测试和Web测试，如果成功完成，构建质量将自动设置为“开发”。当有人将构建质量更改为“In-Staging”时，这会导致将任何以前的“In-Staging”构建设置为“Rejected”，并导致在更新配置文件以指向正确的服务器时将该构建推送到我们的Staging服务器。（我为此使用了TFS部署器和PowerShell脚本）

QA对我们的暂存服务器进行测试。一旦他们感到满意，生产团队将构建质量更改为“生产”。这将导致生成被发送到生产区域，然后手动复制到正确的位置。完成后，生产部门通知开发部门，开发部门随后将该版本分支到生产文件夹中。QA还收到通知，由QA进行一系列生产测试，以验证一切是否如预期的那样工作

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

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

---

尽管我们的DBA正在使用Database Edition（GDR），但他们对自动部署的控制级别还没有印象深刻。我希望Rosario能为产品线带来更好的部署控制；但在此之前，我们有TFS部署器和powershell

我们使用数据库项目为SQL脚本提供版本控制。我们还喜欢使用VisualStudio环境来编辑SQL；对于我们的一些新开发人员来说，它比query analyzer更容易使用。

我在一些付费项目中使用过它们，我认为这是一个很棒的工具。也就是说，我看到了一些问题

如果数据库项目文件夹中的.dat文件与数据库的临时实例不同步，架构比较将给出不准确的结果。不确定这是如何发生的，请仔细检查模式比较，如果出现问题，请（在关闭解决方案后）清除.dat文件

如果您有20多个数据库，它们相互引用并使用循环引用。。。会痛的。我还没有弄明白如何将其扩展到那个场景。GDR2似乎提供了一些希望

---

Shog你应该回到关于模式比较的评论中，这是一个关键的数据块，让我知道他没有使用VS data Dude。你能稍微扩展一下你的版本控制结构吗？你能告诉我如何在VS中生成不同的脚本吗？