我最近尝试过(SQL 2008版本)，我觉得它们还可以。唯一的问题是向导没有足够智能，不能在不先删除所有数据的情况下更新数据库结构。这是这些项目没有实际应用的原因吗？
实际上从来没有见过任何人使用它们或者提到它们。除非你特别搜寻，否则博客和论坛中也找不到它们的任何信息。
它们有什么问题吗？
有人在使用Visual Studio中的“数据库项目”吗？
18
- Disappointed by SO
1
你应该回复评论，关于模式比较的重要数据，并让我知道他没有使用VS Data Dude。 - JoshBerke
5个回答
9
我使用Visual Studio Database Edition中的数据库项目。这是一个很棒的工具。基本上您需要定义整个架构，创造出创建脚本后将其加入源代码控制。然后它内置了一些工具以生成差异脚本，这些脚本不会删除数据。
此外，它还有数据比较工具，可以比较数据库之间的数据并生成使它们相同的脚本。
最近的GDR发布增加了一些有趣的功能。如果你使用它们内置的部署方法，似乎可以生成部署包，当你运行它时，它会分析目标数据库并仅应用差异。
如果您使用Team Studio - Team Suite或Development版，则可以使用Database Edition。
试试看吧，这是数据库开发的一个很好的进化。
此外，它还有数据比较工具，可以比较数据库之间的数据并生成使它们相同的脚本。
最近的GDR发布增加了一些有趣的功能。如果你使用它们内置的部署方法，似乎可以生成部署包，当你运行它时，它会分析目标数据库并仅应用差异。
如果您使用Team Studio - Team Suite或Development版，则可以使用Database Edition。
试试看吧，这是数据库开发的一个很好的进化。
- Josh
1
你能指导我如何在VS中生成差异脚本吗？ - vittore
8
像Glennular一样，我们正在使用它们来对我们的模式和存储过程进行版本控制。
尽管我们有一个相当先进的版本控制结构（CI、自动部署到开发、单击部署到阶段和生产环境），但我们不包括任何数据库项目在其中。我们还不信任它。
更新（针对Out In Space）： 我们为公司的各个功能区域（销售、市场等）设置了单独的TFS项目。在每个TFS项目中，我们都有一个Main和Production文件夹。我们还有一个TFS项目包含数据库项目，另一个包含公共程序集/Visual Studio项目。
发布时，我们从Main分支到Production分支。我们没有阶段分支，因为我们变化太快了。正确或错误，我们的生产率在一定程度上衡量我们每周做的生产级别发布的数量；错误修复、新功能等。
CI设置在Main分支上，以使每个检入导致Build服务器部署到我们的DEV环境。然后运行单元和Web测试，并且如果成功完成，则自动将构建质量设置为“开发”。当有人将构建质量更改为“在Staging中”时，这会导致以前的“在Staging中”的构建被设置为“拒绝”，并导致将该构建推送到我们的暂存服务器，同时更新配置文件以指向正确的服务器。（我使用TFS Deployer和PowerShell脚本完成此操作）
QA在我们的暂存服务器上进行测试。一旦他们满意，生产团队将构建质量更改为“生产”。这会导致构建发送到一个生产区域，然后手动复制到正确位置。完成后，生产通知开发人员，然后将该版本分支到Production文件夹中。QA也会收到通知，然后执行一系列生产测试以验证所有内容确实按预期工作。
我们已设置报告，以显示生产发布之间存在的更改，以便我们知道正在部署的每个检入。这可以防止出现未知问题，例如数据库更改等或其他潜在的破坏性代码。
此外，我们的BA通过Team System Web Access跟踪工作项，并且知道这些项何时在生产环境中。
尽管我们的DBA使用Database Edition（GDR），但他们对自动部署的控制水平并不满意。我希望Rosario会为产品系列带来更好的部署控制；但在那之前，我们有TFS Deployer和PowerShell。
尽管我们有一个相当先进的版本控制结构（CI、自动部署到开发、单击部署到阶段和生产环境），但我们不包括任何数据库项目在其中。我们还不信任它。
更新（针对Out In Space）： 我们为公司的各个功能区域（销售、市场等）设置了单独的TFS项目。在每个TFS项目中，我们都有一个Main和Production文件夹。我们还有一个TFS项目包含数据库项目，另一个包含公共程序集/Visual Studio项目。
发布时，我们从Main分支到Production分支。我们没有阶段分支，因为我们变化太快了。正确或错误，我们的生产率在一定程度上衡量我们每周做的生产级别发布的数量；错误修复、新功能等。
CI设置在Main分支上，以使每个检入导致Build服务器部署到我们的DEV环境。然后运行单元和Web测试，并且如果成功完成，则自动将构建质量设置为“开发”。当有人将构建质量更改为“在Staging中”时，这会导致以前的“在Staging中”的构建被设置为“拒绝”，并导致将该构建推送到我们的暂存服务器，同时更新配置文件以指向正确的服务器。（我使用TFS Deployer和PowerShell脚本完成此操作）
QA在我们的暂存服务器上进行测试。一旦他们满意，生产团队将构建质量更改为“生产”。这会导致构建发送到一个生产区域，然后手动复制到正确位置。完成后，生产通知开发人员，然后将该版本分支到Production文件夹中。QA也会收到通知，然后执行一系列生产测试以验证所有内容确实按预期工作。
我们已设置报告，以显示生产发布之间存在的更改，以便我们知道正在部署的每个检入。这可以防止出现未知问题，例如数据库更改等或其他潜在的破坏性代码。
此外，我们的BA通过Team System Web Access跟踪工作项，并且知道这些项何时在生产环境中。
尽管我们的DBA使用Database Edition（GDR），但他们对自动部署的控制水平并不满意。我希望Rosario会为产品系列带来更好的部署控制；但在那之前，我们有TFS Deployer和PowerShell。
- Chris Lively
1
你能详细介绍一下你的版本控制结构吗？ - Robert S.
5
我们使用它们。我们保留所有模式创建/更新脚本和存储过程。主要目的是将项目连接到SourceSafe或SVN。
这是一种简单的方法来保持您的SQL脚本进行版本控制。
在VS中尝试进行一些SQL测试有点古怪，但你可以想办法克服它。
更新：
实际上，我们已经将其构建到我们的部署脚本中，我们的部署工具会经过DB项目（除了标记的文件夹）并运行所有脚本。我们只需构建一个快速的工具即可运行该项目。如果有其他解决方案来部署DB项目，那将非常有帮助。
这是一种简单的方法来保持您的SQL脚本进行版本控制。
在VS中尝试进行一些SQL测试有点古怪，但你可以想办法克服它。
更新：
实际上，我们已经将其构建到我们的部署脚本中，我们的部署工具会经过DB项目（除了标记的文件夹）并运行所有脚本。我们只需构建一个快速的工具即可运行该项目。如果有其他解决方案来部署DB项目，那将非常有帮助。
- Glennular
1
我在几个付费项目中使用过它们，认为这是一个很棒的工具。但是，我也遇到了一些问题。
如果您的数据库项目文件夹中的.dat文件与临时数据库实例不同步，则模式比较将给出不准确的结果。不确定如何发生这种情况，请仔细查看模式比较，并在关闭解决方案后删除.dat文件（如果出现问题）。
如果您有20多个数据库，并且它们相互引用并使用循环引用...那将会很困难。我还没有找到如何使其适应这种情况的方法。GDR 2似乎提供了一些希望。
- Frank Schwieterman
1
我们使用数据库项目来为我们的SQL脚本提供版本控制。我们也喜欢使用Visual Studio环境来编辑SQL；对于一些新手开发人员来说，它比查询分析器更容易使用一些。
- Out Into Space
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
- 相关问题
- 41 有人在Visual Studio中找到了PowerShell语法高亮或IntelliSense插件吗？
- 11 有使用Visual Studio Shell的经验吗？
- 5 有人在Windows 7上使用Visual Studio 2008的经验吗？
- 16 Visual Studio MySQL 数据库项目
- 5 Visual Studio 中是否有“ZIP 项目”？
- 4 Visual Studio IDE 能够处理的项目大小有限制吗？
- 6 Visual Studio 2010数据库项目，有可视化方式吗？
- 3 Visual Studio数据库项目构建错误
- 33 有人在Windows 7上使用Visual Studio 6成功了吗？
- 4 使用Firebird的Visual Studio数据库项目