自从最初发布该问题以来，我一直在设法解决这个问题的答案。这很困难，因为VS2010并不是要描述该工具的功能和优势。这是关于说服读者对其数据库开发方法进行根本性改变。不容易。
经验丰富的数据库专业人员可以回答这个问题，其背景知识涵盖DBA，developer / 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)
历时4年的5年sprint总共增加了一些有趣的版本脚本，并且需要额外的人工处理以最大程度地减少对部署时间的影响。
那么SSMS有什么问题吗？不，它对管理和管理SQL Server有好处。它甚至不假装要帮助数据库开发人员完成（有时）非常复杂的变更管理任务。
如果无法从源代码构建数据库的每个版本并将其升级到任何将来的版本，则源代码管理已损坏。如果您不这样认为，请询问Eric Sink。
SSMS + <-插入模式比较工具->呢？
这绝对是朝正确方向迈出的一步，并且省去了维护脚本所需的大量手动工作。但是（而且很大），通常涉及手动步骤。
流行的模式比较工具可以完全自动化，并且可以集成到构建过程中。但是，以我的经验，比较普遍的做法是手动运行比较，将生成的脚本盯起来，检入源代码管理，然后手动执行以进行部署。不好。
每当我们容易犯错的人必须参与构建或部署过程时，我们都会引入风险，并使过程不可重复。
如果您和您的团队是拥有全自动模式比较和部署的少数团队，那么您就万事大吉了！你们最有可能对VS2010提供的好处持开放态度：
- 您已经接受手动操作很危险。
- 您会看到自动化的价值。
- 您愿意花费必要的时间使它正常工作。
如果您不能单步创建构建，也不能单步部署，则开发和部署过程将会中断。如果您不这样认为，请询问Joel Spolsky。
为什么选择VS2010？
@NickChammas提出的问题是寻找杀手级功能，以证明VS2010为什么会改变数据库开发的游戏规则。我认为我不能以此为依据。
也许可笑的是，在其他人看到此工具存在缺陷的地方，我看到了采用的强烈理由：
- 您将不得不改变自己的方法。
- 您和您的团队将被迫以不同的方式工作。
- 您将必须详细评估每个更改的影响。
- 您将被引导着使每一个改变都是幂等的。
如果您是项目中唯一的DBA，负责管理对数据库的所有更改，那么这种推理听起来很荒谬可笑。但是，如果您认为@BrentOzar有一个要点，而新规则之一是每个人都是DBA，那么您将需要以团队中每个开发人员都能使用的方式控制数据库更改。
对于某些开发人员而言，采用数据库项目可能需要一种思维上的转变（旧习惯很难改变），或者至少改变流程或工作流。已经开发了生产数据库代表当前数据库版本的数据库应用程序的开发人员，
将需要采用基于源代码的方法，其中源代码将成为对数据库进行更改的工具。在Visual Studio数据库项目中，项目和源代码是数据库架构的“真相的一个版本”，并使用开发人员或组织可能已在其应用程序堆栈的其他部分使用的SCM工作流程进行管理。对于数据，生产数据库应保持应有的“真实版本”。
我们已经实现了成功采用VS2010方法进行数据库开发所必需的根本转变。
将您的数据库视为代码
无需更改实时数据库。每个数据库更改将遵循与应用程序更改相同的模式。修改源，构建，部署。这不是Microsoft的临时改变，这是SQL Server的未来。数据库作为代码将保留下来。
数据库开发人员为应用程序的版本定义对象的形状，而不是如何将数据库引擎中的现有对象更改为所需的形状。您可能会问自己：如何针对已经包含客户表的数据库进行部署？这是部署引擎发挥作用的地方。如前所述，部署引擎将采用模式的编译版本，并将其与数据库部署目标进行比较。差异引擎将生成必要的脚本，以更新目标架构以匹配您从项目中部署的版本。
是的，还有其他工具也遵循类似的模式，并且对于超出我的回答限制范围的项目，值得同等考虑。但是，如果您使用的是Visual Studio和Team Foundation Server ALM，我认为它们无法竞争。
VS2010数据库项目有什么问题？
- 他们并不完美。但是，如果您知道局限性和问题区域，则可以解决它们。
- 复杂的数据移动仍需要注意和注意，但可以通过部署前/部署后的脚本来解决。
编辑：那你的意思是什么？
@AndrewBickerton在评论中提到我没有回答原始问题，因此我将尝试总结“为什么在我的数据库开发中为什么应该使用Visual Studio 2010 over SSMS？” 这里。
- SSMS不是数据库开发工具。是的，您可以使用SSMS开发TSQL，但是它不提供VS2010的丰富IDE功能。
- VS2010提供了一个将数据库视为代码的框架。
- VS2010为您的数据库代码带来了静态代码分析。
- VS2010为您提供了完全自动化构建部署测试周期的工具。
- SQL2012和Visual Studio vNext扩展了数据库项目的功能。现在就熟悉VS2010，您就可以在下一代数据库开发工具上抢先一步。