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

#1 楼

老实说，实际上我对VS2010有点不了解。我认为老式的用于存储过程的创建表脚本和文件更易于使用。如果您需要模式管理，则可以花几百美元购买Redgate SQL Compare Pro。

如果您确实需要数据库建模工具，那么Powerdesigner甚至Erwin的工作要好得多，尽管它们并不是特别便宜。

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



SSMS具有一个用户界面，该界面“很好”地适用于SQL开发。仅仅构建和使用创建脚本比VS2010迫使您跳过去要方便得多。灵活得多（+ SSMS）。
VS2010具有基本的架构管理（即差异/补丁脚本生成）（+ VS2010）。但是，它并不是那么好，并且存在一些缺陷。例如，它与名称约束匹配。如果您在列上具有检查约束或默认约束而未命名，则SQL Server在幕后会生成一个随机名称。如果将脚本安装在其他计算机上，这将使VS2010感到困惑，因为约束可能具有不同的名称。 Redgate更便宜，更好。 （+ VS2010，但有缺陷）。
VS2010确实笨拙-您需要为每个表或其他数据库对象使用一个文件。本质上，您必须以VS2010方式进行操作，这非常麻烦。 （-VS2010）
VS2010也有些脆弱，源代码管理集成也很不稳定。即使在简单的数据库中，每个表，约束，存储过程，索引和其他数据库对象也是其自己的文件。文件一直被添加到项目中，比使用（例如）C＃的典型编程项目快得多。通过乐观并发，当签入不同步时，它趋向于以静默方式从项目中删除文件。即使具有良好的团队纪律，用户界面对状态的反馈仍然非常差。对于复杂的模型，这将是一场灾难。 （-VS2010-我几乎会认为大型项目的一个令人震惊的缺陷）。
SQL Server附带了SSMS-不能超过价格（+ SSMS）。
VS2010仍然没有具有适当的存储库，例如（例如）PowerDesigner或Oracle Designer。如果不将其安装到数据库中，就无法轻松查询数据模型。 （-VS2010）。

总体而言，我将VS2010评为B级。在一个相对简单的数据库项目中，它很笨拙，有两个事实表，大约有15个维度。

我做过的最大数据模型是用于法院案件管理系统，该系统具有大约560张桌子。对于那种大小的项目，我不建议使用VS2010（我在Oracle Designer上做到了）。本质上，它试图变得聪明，并且这种范例并不能很好地发挥作用。您最好使用PowerDesigner之类的一流建模工具，或者仅手动使用创建表脚本。

SSMS简单可靠，但是手动。您几乎可以无限地控制如何管理模型。将其与诸如Redgate SQL Compare之类的模式管理器以及诸如PowerDesigner之类的体面建模工具相结合，您将获得比VS2010更好的软件包。

摘要
除了（可能）与包含其他项目的VS解决方案集成之外，我不确定是否可以引用任何杀手级功能或优势。如果您已经拥有VS2010 Premium或Ultimate，那么您的.Net工具链中会附带一些有缺陷的数据库开发工具。它将数据库项目集成到VS解决方案中，因此您至少可以使用它来制作sproc部署脚本。

但是，VS没有建模工具可言，因此PowerDesigner甚至Erwin在那算。 Redgate的模式管理要好得多，SQL Compare Pro相当便宜（约400英镑IIRC）。 IMHO SSMS对于T-SQL开发而言要好得多，但是您当然可以在VS2010上做到。

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

另一种方法

我想如果没有VS2010，就不应该过多地放弃VS2010建议至少一种替代方案，并概述其优缺点。为此，我将假设一个大型项目。尽管这几天我主要从事A / P工作，但我参与了一个100多员工年的项目，在该项目中我进行了数据模型（和一些开发工作），还参与了其他几个工作在10个员工年的范围内，我主要在其中工作作为分析师或开发人员。这些天大部分时间我都在数据仓库系统上工作，但较大的项目主要是应用程序。根据我对各种工具的经验，以下是替代工具链的一些建议：


VS2010 Professional或更高版本。您可能会或可能不想使用高级或旗舰版的项目管理功能。
Subversion，AnkhSVN和TortoiseSVN-每天都比TFS更好，并且可以与VS很好地配合使用。还可以在本地存储库中进行并行开发工作流。
用于T-SQL开发的SSMS-项目管理和SC集成不是很好，但是可以很好地用于DB开发工作。
VS2010 DB项目用于跟踪sproc文件-如果您使用SSMS却有些笨拙，但是效果很好。它还将生成部署脚本。
PowerDesigner-更好地建模数据库和管理数据库架构项目。如果您想深入了解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更好的数据库建模和模式管理，更好的版本控制系统，更容易自定义构建和项目工作流程，更好地管理规范和文档。

缺点：集成工具的工作量有限将DB集成到构建过程中。

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

并不是非常高科技或巧妙地集成在一起，但是对于复杂的项目，您可能更喜欢控制而不是可爱的自动化功能。我认为您最好使用一套最好的工具，以及集成它们所需的任何家庭酿造工具和测试脚本。只需尝试使构建（a）相对简单易懂且（b）完全自动化。


DB补丁上的QA。在大型架构上，您可能需要对实时系统进行手动修补，尤其是在修补涉及数据迁移的情况下。例如，如果需要，可能需要具有前滚脚本和回滚脚本来支持撤消更改。在这种情况下，您将需要一种工具来测试该补丁程序是否实际正常工作。如果您在存储库中管理数据库架构，则可以通过先设置数据库并从存储库生成参考数据库来测试脚本。在before数据库上运行补丁脚本应将其与存储库模型同步。可以使用模式比较工具对此进行测试。
最近，我完成了比定制应用程序开发更多的数据仓库和集成工作，因此在大多数情况下，与开发团队相比，我遇到这种情况的频率更高。但是，项目管理工具和方法在管理外部利益相关者方面做得很差。在诸如数据仓库之类的集成项目中，我确实希望看到一个项目管理工具，该工具在面对程序管理时确实能够推动外部依赖关系（即我无法控制的依赖关系）。在任何非平凡的集成项目中，外部依赖关系都是造成浪费时间的最大因素。

#2 楼

自从最初发布该问题以来，我一直在设法解决这个问题的答案。这很困难，因为VS2010并不是要描述该工具的功能和优势。这是关于说服读者对其数据库开发方法进行根本性改变。并非易事。

经验丰富的数据库专业人员可以回答这个问题，其背景知识涵盖DBA，developer / dba以及OLTP和数据仓库。我无法一口气地在数据库开发的每个方面都采用这种方法，因此我将尝试为特定的情况做个例子。

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


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

如果您正在评估VS2010进行数据库开发，那么您的圣经将是Visual Studio数据库Visual Studio ALM Rangers的指南。

我们接下来要去...

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

数据。如果不是那些讨厌的数据，那么数据库开发将是一个轻而易举的事。我们可以只删除每个发行版上的所有内容，而不必理会麻烦的变更管理。


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


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周冲刺加了一些有趣的版本脚本，并且需要额外的人工处理，以最大程度地减少对部署时间的影响。

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在评论中提到我没有回答原始问题，因此我将尝试总结一下“为什么我应该在SSMS上使用Visual Studio 2010？用于我的数据库开发？”在这里。


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

#3 楼

如果您不了解SSMS或使用了第三方工具，则VS可能会很棒。如果您使用Red Gate工具进行模式比较等，则VS中的差距会突出。免费的SSMS插件也是如此。

源代码控制位会误导您：生产数据库中的内容是您的参考复制。不是开发人员使用的东西。请参见


https://stackoverflow.com/q/1597085/27535
https://stackoverflow.com/q/4433153/27535

>

#4 楼

我在SSRS报表设计和SSIS包中广泛使用Visual Studio（好吧，BIDS）。即使在Management Studio中，我也做得不好。 Visual Studio是一个更加完整和集成的开发环境，它也可以更好地连接到Source Control系统中。价格全都体现出来了！

#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中选择11种SSMS。

#6 楼

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

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

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

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

对于数据库项目来说，这是一个很好的分步过程。

#7 楼

我使用SSMS比使用VS2010多，因为在安装SQL Server时就在那里。恕我直言，这可能是SSMS比VS2010多使用的最重要原因。
我也确实发现像Red-Gate这样的供应商正在推出与SSMS集成的工具，而不一定是与VS2010集成的工具。这可能是积极的，因为它使您可以改进Microsoft没有的SSMS。一个例子就是Red-Gate的SQL Source Control，它是SSMS的附加组件，它使您可以将SSMS连接到公司的Source Control系统，无论是Visual Team Foundation还是现有的。 VS2010具有此内置功能，但与Reg-Gate工具的价格相比，我节省了很多钱，而不必购买VS2010。

我认为总体而言，归结为偏好，您可以使用如果您正在训练一个新手并且在VS2010上对他们进行培训，那么这将成为他们的偏爱，因为他们知道如何解决这个问题。

如果您开始使用SQL在Server 2012中，您可能已经注意到SSMS正在缓慢但肯定地获得VS2010的组成。因此，最终您可能无法分辨它们之间的区别。