Visual Studio 2010和SQL Server 2008脚本和数据库更新的源代码管理工具？

Question

我们目前正在使用Visual Studio 2010和SQL Server 2008 R2 - 开发使用(多个)SQL Server数据库的Intranet ASP.NET应用程序.

我们一直在为源代码控制中的SQL Server存储脚本(用于数据库),与SQL Server Management Studio(SSMS)或Visual Studio等任何工具分开.也就是说,我们有一组包含表,存储过程等脚本的文本文件; 我们在更新它们之前(例如在Management Studio中)直接检查这些来源和源代码控制,然后重新检入它们(然后使用SSMS中的脚本来更新数据库).

我们现在想采用更加综合的方法.

我已看过一些的问题/答案在StackOverflow上就有关SQL Server的源代码控制(其中一些可以追溯到StackOverflow上的几乎开始),但没有发现任何优秀的解决方案.此外,某些条目早于Visual Studio 2010或SQL Server 2008或某些现在可用的工具.

我还阅读了有关此主题的其他文章,例如Troy Hunt的文章(例如:http://www.troyhunt.com/2011/02/automated-database-releases-with.html)和K. Scott Allen的文章(例如:http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-views-stored-procedures-and-the-like.aspx).

SQL Server Management Studio具有"数据库项目"的概念,但这显然是一个不推荐使用的功能,不建议用于新开发.

我们目前正在考虑的方法是:

(1)在Visual Studio 2010中创建SQL Server 2008数据库项目,并将其连接到源代码管理(例如,TFS或VSS).[此选项可能需要Visual Studio的Premium或Ultimate或Team Database Edition.

此方法将脚本视为"主",并从中创建/更新数据库以与脚本版本同步.

这种方法的理想特征是:全局搜索,查找/替换,重构,有关缺失索引的警告或无效引用的项目等.

缺点是:没有用于表和其他项的GUI设计器,通过对列的一些更改很容易丢失数据(因为"alter"脚本删除了列并重新创建它),缺少"format document"命令(在Visual Studio中可用)用于Web项目,但不用于数据库项目).

(2)在SQL Server Management Studio中使用Red-gate SQL源代码控制(和SQL Compare).

此方法基本上将数据库视为"主",并根据数据库设计的更改更新脚本.在许多方面,这与许多小型开发团队的工作方式更为匹配.

这种方法的主要优点是您可以使用所有SSMS工具和设计器.

缺点是设计完整性检查较少,没有查找/替换或全局搜索(不安装其他附加组件),使用SQL源代码控制生成的脚本在语法上与SSMS或Visual Studio本机生成的脚本不同(最终结果是一样的).

=====

您是否有替代方法的建议,您是否使用/喜欢将SQL Server数据库的源代码控制集成到SQL Server Management Studio或Visual Studio 2010中的特定工具或实用程序,以及如何更新/同步开发和生产数据库有变化吗？

我还为此目的查看了一些其他软件实用程序/工具(其中一些已在其他StackOverflow主题中提到):

SQL Examiner(一种可能性,虽然它是一个完全独立的工具;没有集成到SSMS或Visual Studio中)

LiquiBase(Apache/Java,还没有.NET)

NeXtep(尚未支持SQL Server)

DBSourceTools(尚未集成)

Answer 1

我的Org已经将它们用于两个不同的项目,我已经变得非常偏爱RedGate工具.正如您所提到的那样,要获得完整功能,您需要使用RedGate的整个工具集,但是您也可以获得很多额外功能(包括重构或全局搜索/替换).为了将DEV同步到TEST/QA/PROD环境,我使用他们的Compare产品来构建脚本集(通常需要进一步检查).我真的不相信任何更新使用中架构的工具,除非我准备快速恢复它.

相比之下,我发现MS工具过于复杂,这使得它们有些不灵活.当我们在需要与项目同步的数据库中进行一些更改时,我们发现自己陷入了困境,但项目中的更改不允许在没有来自数据库的更改的情况下构建...它最终在整个catch-22场景需要大量的手动编辑(并导致测试和购买RedGate工具).

Answer 2

您可能需要考虑的另一个因素或标准是您和您的团队最适合编写脚本\存储过程等.

我们过去已经评估过Visual Studio Team Database Edition(或者现在称之为的任何东西),并且得出了一个令人遗憾的结论:我们在Visual Studio中编写SQL时感到很不舒服.作为使用SSMS编写SQL的团队,我们的工作效率更高.你当然可能会发现相反的情况属实.

我们也正在评估Red-Gate的SQL源代码控制工具.对我们来说最大的好处是它在SSMS中工作并且相对无摩擦.无论出于何种原因,他们的模型都会更好地映射我们如何进行SQL开发工作.

关于部署,两种产品似乎都倾向于稍微倾向于将更改部署到服务器上的数据库的开发工作.从ISV的角度来看,这使得生成在您环境之外的数据库上执行的部署脚本(例如,托管在客户端服务器上的数据库)更具挑战性.

出于这个原因,我个人喜欢Microsoft采用的方法,您可以在其中生成描述数据库模式的模式文件.我可能会遗漏一些东西,但我记得这个模式文件是用于生成更新目标数据库的脚本的.此解决方案的优点在于,根据目标数据库的状态,更改脚本可能会有所不同.

不幸的是,如果您没有"DBPro"可用(再次考虑客户端站点),您将继续使用VSDBCMD从架构文件生成更改脚本.虽然这很有效,但如果Microsoft公开了VSDBCMD的API,那么可以创建一个GUI,使非开发人员类型更容易执行,而不必使用命令行工具.

很难想象VS Team Database Edition将来不会获得额外的功能,所以投注MS可能并不是一场赌博,当然你可以忍受这个工具目前的缺点.