为什么我应该在数据库开发中使用 Visual Studio 2010 而不是 SSMS？

Question

Visual Studio 2010 引入了数据库项目和一整套相关功能，据说可以促进数据库开发。多年来，我一直使用 SQL Server Management Studio (SSMS) 进行数据库开发，没有出现任何问题。

• 当 SSMS 对我有用时，我为什么要为 VS2010 烦恼？具体来说，它比 SSMS 做得更好的是什么？
• 但也许我的前提是不正确的，SSMS 在数据库开发方面仍然胜过 VS。如果是这样，那在哪些具体方面是正确的？

Answer 1

实际上，老实说，我对 VS2010 有点不知所措。我认为老式的创建表脚本和存储过程文件更容易使用。如果您需要模式管理，那么您可以花几百美元获得 Redgate SQL Compare Pro。

如果您真的需要一个数据库建模工具，那么 Powerdesigner 甚至 Erwin 会做得更好，尽管它们并不是特别便宜。

虽然我更喜欢 SSMS，但我两个都用过。一些优点和缺点：

• SSMS 的用户界面“非常适合”用于 SQL 开发。只是构建和使用创建脚本比 VS2010 强迫您跳过的箍要方便得多。更加灵活（+ SSMS）。

• VS2010 具有基本的模式管理（即差异/补丁脚本生成）（+ VS2010）。然而，它并不是那么好，并且有一些缺陷。例如，它匹配名称的约束。如果您在未命名的情况下对列进行了检查或默认约束，SQL Server 会在后台生成一个随机名称。如果将脚本安装在不同的机器上，这将混淆 VS2010，因为约束可能具有不同的名称。红门更便宜，更好。（+ VS2010，但有缺陷）。

• VS2010 真的很笨拙——您需要为每个表或其他 DB 对象创建一个文件。本质上你必须用VS2010的方式做事，这很麻烦。(- VS2010)

• VS2010 也有些脆弱，源代码控制集成也很脆弱。即使在一个简单的数据库上，每个表、约束、存储过程、索引和其他数据库对象都是它自己的文件。文件一直被添加到项目中，比使用（比如）C# 的典型编程项目快得多。使用乐观并发，它倾向于在签入不同步时悄悄地从项目中删除文件。即使有良好的团队纪律，用户界面关于状态的反馈也很差。这对复杂模型来说将是一场灾难。（-VS2010 - 我几乎认为这是一个大型项目的停止缺陷）。

• SSMS 随 SQL Server 一起提供 - 无法超越价格（+ SSMS）。

• VS2010 仍然没有像（比如说）PowerDesigner 或 Oracle Designer 这样的合适的存储库。如果不将数据模型安装到数据库中，就无法轻松查询数据模型。（ - VS2010）。

总的来说，我会给 VS2010 打分 B-。在一个有两个事实表和大约 15 个维度的相对简单的数据库项目上，它是笨拙的。

我做过的最大的数据模型是一个法庭案件管理系统，它有大约 560 个表。我不会为这么大的项目推荐 VS2010（我是在 Oracle Designer 上这样做的）。从本质上讲，它试图变得聪明，而范式并没有真正奏效。您最好使用 PowerDesigner 之类的同类最佳建模工具或仅使用手动创建表脚本。

SSMS 简单可靠，但需要手动操作。您对管理模型的方式几乎拥有无限的控制权。将它与 Redgate SQL Compare 等模式管理器以及 PowerDesigner 等不错的建模工具结合使用，您将获得比 VS2010 更好的软件包。

总结 除了（可能）与包含其他项目的 VS 解决方案集成之外，我不确定我是否可以引用任何杀手级功能或好处。如果您已经拥有 VS2010 高级版或终极版，那么您的 .Net 工具链中就会出现一个有缺陷的数据库开发工具。它会将 DB 项目集成到您的 VS 解决方案中，因此您至少可以使用它来制作 sproc 部署脚本。

但是，VS 没有建模工具可言，因此 PowerDesigner 甚至 Erwin 在这一点上更好。Redgate 的模式管理要好得多，SQL Compare Pro 相当便宜（大约 400 英镑 IIRC）。恕我直言，SSMS 对于 T-SQL 开发效果更好，但您当然可以使用 VS2010 来实现。

VS2010 高级版并不比同类最佳的数据库建模工具便宜多少，而 VS2010 终极版至少同样昂贵。以与 VS 项目紧密集成为代价，使用第三方工具可能会做得更好。

替代

我想人们不应该在没有提出至少一种替代方案并概述其优缺点的情况下过多地贬低 VS2010。为此，我将假设一个大型项目。虽然这些天我主要做 A/P 工作，但我参与了一个 100 多个员工年的项目，在那里我做了数据模型（和一些开发工作）和其他一些 10 个员工年范围内的项目，我主要在那里工作作为分析师或开发人员。这些天我主要从事数据仓库系统的工作，但较大的项目主要是应用程序。根据我使用各种工具的经验，这里有一些关于替代工具链的建议：

• VS2010 专业版或更高版本。您可能想也可能不想使用高级或终极的项目管理功能。
• Subversion、AnkhSVN 和 TortoiseSVN - 任何一天都比 TFS 更好，并且与 VS 配合得很好。它也非常适合为并发开发工作流使用本地存储库。
• 用于 T-SQL 开发的 SSMS - 项目管理和 SC 集成不太好，但适用于 DB 开发工作。
• 用于跟踪 sproc 文件的 VS2010 DB 项目 - 如果您使用 SSMS 但工作正常，则有点笨拙。它还将生成部署脚本。
• PowerDesigner - 在建模数据库和管理 DB 模式项方面做得更好。如果您想深入研究 MDA，它也可以使用 UML。如果您想从对象模型驱动您的数据库设计，您可以考虑使用 Sparx EA。在我见过的任何 CASE 工具中，Meta CASE（可扩展元模型）做得最好，尽管它的数据库建模还有一些不足之处。
• SQL Compare pro - 使用它来生成数据库补丁脚本或测试手动补丁脚本（见下面的 1）。
• Framemaker - 如果您有多个分析师在制定规范，则比 Word 更稳定和更好的群件功能。它还支持条件包含，因此您可以拥有隐藏 WIP 更改的规范版本。MIF 和 MML 使得将 API 文档和数据字典集成到规范文档中变得相当容易。这样做非常有用，因为您可以在规范中交叉引用它们。文本标签锚点使交叉引用在重新导入时保持稳定。您还可以使用 TCS 将文档单一来源为 PDF、HTML 和 CHM 输出。
• 开源问题跟踪器 - 许多优秀的开源问题（例如 TRAC、Bugzilla 等我用过的几个）。开源的更容易修改或集成到自定义工作流程中，而且您无法超越价格。
• NUnit 或其他测试工具——任何最适合您需求的自动化测试工具。
• 除了 MS 项目之外的任何东西 - 被认为是有害的。MS 项目非常内向，将项目计划强制转换为一个模型，该模型不能有效地表示不确定性、风险或对利益相关者或其他第三方的依赖（见下文 2）。

优点：比 VS2010 更好的数据库建模和模式管理，更好的版本控制系统，更容易定制构建和项目工作流程，更好地管理规范和文档。

缺点：更多的工具集成工作，有限的数据库集成到构建过程中。

假设：假设更改/发布过程的控制比数据库模式的自动化或紧密集成的发布管理更重要。还假设自动数据库模式管理不是 100% 可靠的。

不是非常高科技或巧妙的集成，但对于复杂的项目，您可能对控制比可爱的自动化功能更感兴趣。我认为你最好使用一组最好的工具以及任何自制的构建和测试脚本来集成它们。尽量保持构建 (a) 相对简单易懂和 (b) 完全自动化。

1. 对数据库补丁进行 QA。在大型模式上，您可能希望对实时系统进行手动修补过程，尤其是在修补程序涉及数据迁移的情况下。例如，可能需要有前滚和回滚脚本来支持在必要时回退更改。在这种情况下，您将需要一个工具来测试补丁是否真正正常工作。如果您在存储库中管理数据库架构，您可以通过设置前数据库并从存储库生成参考数据库来测试脚本。在 before 数据库上运行补丁脚本应该将它与存储库模型同步。可以使用模式比较工具对此进行测试。

2. 最近我做了比定制应用程序开发更多的数据仓库和集成工作，所以我遇到这种情况的频率比开发团队在大多数情况下都要多。然而，项目管理工具和方法在管理外部利益相关者方面做得很差。在像数据仓库这样的集成项目中，我真的很想看到一个项目管理工具，它在面对程序管理时真正推送外部依赖项（即我无法控制的依赖项）。在任何重要的集成项目中，外部依赖是浪费时间的最大驱动因素。

Answer 2

自从它最初发布以来，我一直在琢磨如何构建这个问题的答案。这很困难，因为 VS2010 的情况不是描述工具的特性和优点。这是关于说服读者对他们的数据库开发方法进行根本性转变。不容易。

这个问题的答案来自经验丰富的数据库专业人士，他们的背景涵盖 DBA、开发人员/dba 以及 OLTP 和数据仓库。对我来说，一次性针对数据库开发的每个方面都解决这个问题是不可行的，所以我将尝试为特定场景提出一个案例。

如果您的项目符合这些标准，我认为 VS2010 有一个令人信服的案例：

• 您的团队正在使用 VS2010 进行应用程序开发。
• 您的团队正在使用 TFS 进行源代码控制和构建管理。
• 您的数据库是 SQL Server。
• 您的团队已经拥有或对 VS 自动化测试感兴趣。

如果你的数据库开发评估VS2010，你的圣经将是Visual Studio的数据库向导从Visual Studio的ALM流浪者。后面没有引用的任何引用都将来自本文档。

那我们走吧……

为什么数据库开发过程与应用程序开发不同？

数据。如果不是那些讨厌的数据，数据库开发将是一件轻而易举的事。我们可以在每个版本中删除所有内容，而忘记这个麻烦的变更管理。

数据的存在使数据库更改过程变得复杂，因为当应用程序开发工作引入影响数据库表或其他数据模式的形状的更改时，数据通常会被迁移、转换或重新加载。在整个变更过程中，必须保护生产质量数据和运营状态免受可能危及其完整性、价值和对组织有用性的变更。

SSMS 有什么问题？

它被称为 SQL Server Management Studio 是有原因的。作为一个独立的工具，如果您要遵循公认的最佳实践，管理您的开发工作是不切实际的。

单独使用脚本，要有意义地将既定的源代码控制实践应用到您的开发中，您必须同时维护对象定义（例如 CREATE TABLE 脚本）和更改脚本（例如 ALTER TABLE），并努力确保它们保持同步。

用于更改表的版本链很快变得非常愚蠢。一个非常简单的例子：

-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))

-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))

-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))

到版本 3，数据库更改脚本包含：

ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)

如果此数据库的实时版本是版本 1，而我们的下一个版本是版本 3，则下面的脚本将是所有需要的，但将执行两个 ALTER 语句。

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

5 年 4 周的 sprint 加起来是一些有趣的版本脚本，需要额外的人工处理以尽量减少对部署时间的影响。

那么SSMS有什么问题吗？不，它有利于管理和管理 SQL Server。它甚至不假装是协助数据库开发人员完成（有时）管理变更的非常复杂的任务。

如果您无法从源代码构建数据库的每个版本并升级到任何未来版本，那么您的源代码控制就会被破坏。如果您不这么认为，请询问 Eric Sink。

SSMS + <--插入模式比较工具-->怎么样？

这绝对是朝着正确方向迈出的一步，并消除了维护脚本所需的大量手动工作。但是（这是一个很大的但是），通常涉及手动步骤。

流行的模式比较工具可以完全自动化并集成到构建过程中。但是，根据我的经验，更常见的做法是手动运行比较，观察生成的脚本，签入源代码控制，然后手动执行以进行部署。不好。

每当我们容易犯错的人必须参与构建或部署过程时，我们都会引入风险，并使该过程不可重复。

如果您和您的团队是少数拥有全自动模式比较和部署的人，那么向您致敬！你们最有可能对 VS2010 所提供的好处持开放态度：

• 您已经接受手动步骤是危险的。
• 您会看到自动化的价值。
• 你愿意投入必要的时间来让它发挥作用。

如果您无法一步创建构建或一步部署，那么您的开发和部署过程就会中断。如果您不这么认为，请询问 Joel Spolsky。

为什么是 VS2010？

@NickChammas 提出的问题是寻找能够证明 VS2010 是数据库开发游戏规则改变者的杀手级功能。我不认为我可以在这个基础上提出这个案子。

也许可笑的是，在其他人认为此工具存在缺陷的地方，我看到了采用该工具的充分理由：

• 你将不得不改变你的方法。
• 您和您的团队将被迫以不同的方式工作。
• 您必须详细评估每个更改的影响。
• 您将被引导使每个更改都具有幂等性。

如果您是项目中唯一的 DBA，负责管理对数据库的所有更改，那么这种推理听起来一定很荒谬，近乎荒谬。但是，如果您认为 @BrentOzar 有道理，并且新规则之一是每个人都是 DBA，那么您将需要以团队中的每个开发人员都可以使用的方式控制数据库更改。

对某些开发人员来说，采用数据库项目可能需要精神上的转变（旧习惯很难打破），或者至少需要改变流程或工作流程。开发数据库应用程序（其中生产数据库代表数据库的当前版本）的开发人员 将需要采用基于源代码的方法，其中源代码成为对数据库进行更改的工具。在 Visual Studio 数据库项目中，项目和源代码是数据库架构的“真相的一个版本”，并使用 SCM 工作流进行管理，开发人员或组织可能已将其用于其应用程序堆栈的其他部分。对于数据，生产数据库仍然是它应有的“真相的一个版本”。

我们已经实现了成功采用 VS2010 方法进行数据库开发所必需的根本性转变……

将您的数据库视为代码

不再更改实时数据库。每个数据库更改都将遵循与应用程序更改相同的模式。修改源码，构建，部署。这不是微软暂时改变方向，这是 SQL Server 的未来。数据库即代码将继续存在。

数据库开发人员为应用程序的版本定义对象的形状，而不是如何将数据库引擎中的现有对象变异为所需的形状。您可能会问自己：如何针对已经包含客户表的数据库部署它？这就是部署引擎发挥作用的地方。如前所述，部署引擎将采用已编译版本的架构并将其与数据库部署目标进行比较。差异引擎将生成必要的脚本来更新目标模式以匹配您从项目部署的版本。

是的，还有其他工具遵循类似的模式，对于超出我对答案的限制的项目，它们值得同等考虑。但是，如果您使用 Visual Studio 和 Team Foundation Server ALM，我认为它们无法竞争。

VS2010 数据库项目有什么问题？

• 它们并不完美。但是，如果您了解限制和问题区域，则可以解决它们。
• 复杂的数据移动仍然需要小心和注意，但可以通过部署前/部署后脚本来满足。

编辑：那么你的观点是什么？

@AndrewBickerton 在评论中提到我没有回答最初的问题，所以我会尝试总结“为什么我应该使用 Visual Studio 2010 而不是 SSMS 来开发我的数据库？” 这里。

• SSMS 不是数据库开发工具。是的，您可以使用 SSMS 开发 TSQL，但它不提供 VS2010 丰富的 IDE 功能。
• VS2010 提供了一个框架来将您的数据库视为代码。
• VS2010 为您的数据库代码带来静态代码分析。
• VS2010 为您提供了完全自动化构建-部署-测试周期的工具。
• SQL2012 和 Visual Studio vNext 扩展了数据库项目的功能。现在熟悉 VS2010，您就可以在下一代数据库开发工具上领先一步。

Answer 3

如果您不了解 SSMS 或使用过 3rd 方工具，VS 可能看起来很棒。如果您使用 Red Gate 工具进行模式比较等，VS 中的差距会很明显。还有免费的 SSMS 插件。

源代码控制位具有误导性：生产数据库中的内容是您的参考副本。不是开发人员正在使用的。看

• /sf/ask/111795981/
• /sf/ask/310320741/

Answer 4

我广泛使用 Visual Studio（好吧，BIDS）进行 SSRS 报告设计和 SSIS 包。在 Management Studio 中，我不能做得很好，如果有的话。Visual Studio 是一个更加完整和集成的开发环境，它也能更好地与源代码控制系统挂钩。而这一切都体现在价格上！

Answer 5

老实说，我的投票直接投给了 SQL Server Management Studio，用于数据库设计、开发和（显然）管理。输入更容易：

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

然后点击所有正确的地方。SSMS 是一个很棒的布局，绝对适合使用。我天生就是一名 .NET 软件开发人员。但是在数据库设计和编码方面，我会在 10 次中选择 SSMS 11 次。

Answer 6

没有最佳实践，但使用 VS 2010 数据库项目和源代码控制器（VSS 2010、Subversion 等），您可以对数据库进行版本控制。

我建议您首先将数据库直接设计到 SSMS 中。在您的数据库几乎准备就绪后，将其导入到 VS 2010 数据库项目中。导入完成后，您必须始终将新脚本添加到数据库项目中以跟踪所有修改。您可以使用数据库项目的比较功能从开发服务器获取所有更改并将所有这些脚本直接导入到您的项目中。您现在只需要将更改“提交”到源代码控制器中。

使用这种方法，您可以拥有一个版本化的数据库。您可以发现每个修改的版本并回滚您的更改。

这不是唯一的优势。使用这种项目，您可以将任何数据库与您的项目进行比较以编写更改脚本，并且使用 SQL PowerShell 命令提示符，您可以使用相同的脚本更新所有数据库：此脚本是您的数据库的 XML 架构。它只会执行更新数据库所需的命令。您还可以在数据库中进行单元测试。此处提供了另一篇关于数据库项目的好文章。使用部署功能，您可以拥有前脚本和后脚本。使用这些脚本，您可以进行验证或将数据插入系统表中。

这是数据库项目的一个很好的分步过程。