问题描述
|
我们当前正在使用Visual Studio 2010和sql Server 2008 R2-开发使用（多个）sql Server数据库的Intranet ASP.NET应用程序。
我们已经将sql Server的脚本（用于数据库）存储在源代码管理中，与任何工具（例如sql Server Management Studio（SSMS）或Visual Studio）分开存储。也就是说，我们有一个文本文件集合，其中包含表，存储过程等的脚本；并且我们会在更新它们之前（例如在Management Studio中）将它们检入和检出源代码控制，然后再检入它们（然后使用SSMS中的脚本来更新数据库）。
我们现在想转向一种更综合的方法。
我已经阅读了与sql Server相关的源代码管理中StackOverflow中的一些问题/答案（其中一些问题可以追溯到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版本。]
此方法将脚本视为\“ master \”，并根据该脚本创建/更新数据库以与脚本版本同步。
这种方法的理想功能是：全局搜索，查找/替换，重构，有关缺少索引或引用无效的项目的警告等。
缺点是：没有用于表和其他项目的GUI设计器，可以通过对列进行一些更改来轻易丢失数据（因为\“ alter \”脚本会删除该列并重新创建它），缺少\“ format document \”命令（在Visual Studio中可用于Web项目，但不适用于数据库项目）。
（2）在sql Server Management Studio中使用Red-gate sql源代码控制（和sql比较）。
这种方法实质上将数据库视为“主数据库”，并且根据数据库设计的更改来更新脚本。在许多方面，这与许多较小的开发团队的工作方式更加接近。
这种方法的主要优点是您可以使用所有SSMS工具和设计器。
缺点是设计完整性检查较少，没有查找/替换或全局搜索（无需安装其他加载项），并且使用sql Source Control生成的脚本在语法上与SSMS或Visual Studio本地生成的脚本在语法上有所不同（最终结果是相同的）。
=====
您是否对替代方法有什么建议？是否有特定的工具或实用程序用于/首选将sql Server数据库的源代码控制集成到sql Server Management Studio或Visual Studio 2010中，以及用于更新/同步开发和开发的方法？生产数据库有变化吗？
我还查看了用于此目的的其他一些软件实用程序/工具（其中一些在其他StackOverflow主题中已提及）：
sql检查器（尽管它是一个完全独立的工具，但是可能；未集成到SSMS或Visual Studio中）
LiquiBase（Apache / Java，尚无.NET）
NeXtep（尚无sql Server支持）
DBSourcetools（集成程度不够）
解决方法
我的组织一直在两个不同的项目中使用这两个工具，而我对RedGate工具也很偏爱。正如您提到的要获得全部功能一样，您需要RedGate的整个工具集，但是您还可以获得很多其他功能（包括重构或全局搜索/替换）。为了将DEV同步到TEST / QA / PROD环境，我使用其Compare产品来构建脚本集（通常需要进一步检查）。我真的不相信有任何工具可以更新使用中的模式，除非我准备快速恢复它。
相反，我发现MS工具过于复杂，这使它们有些不灵活。当数据库中有一些需要同步到项目的更改时，我们发现自己很烦，但是项目中的更改不允许没有数据库的更改而无法构建它……最终在整个22类情况下，需要进行大量手动编辑（并导致测试和购买RedGate工具）。
,您可能要考虑的另一个因素或标准是您和您的团队最喜欢编写脚本\\存储过程等的位置。
过去，我们已经评估了Visual Studio Team Database Edition（或目前称为“如今”的任何名称），但得出的不幸结论是，从Visual Studio中编写SQL感到不满意和高兴。作为使用SSMS编写SQL的团队，我们的工作效率更高。当然，您可能会发现相反的事实。
我们也在评估Red-Gate的SQL Source Control工具。对我们来说，最大的好处是它可以在SSMS中运行并且相对平稳。无论出于何种原因，他们的模型都更好地映射了我们倾向于进行SQL开发工作的方式。
关于部署，这两种产品似乎都稍微偏向于将更改部署到服务器上数据库的开发工作。从ISV的角度来看，这使得生成部署脚本要在环境之外的数据库（例如，托管在客户端服务器上的数据库）上执行更具挑战性。
因此，我个人喜欢Microsoft采取的方法，您可以在其中生成描述数据库模式的模式文件。我可能遗漏了一些内容，但我记得该架构文件是用来生成用于更新目标数据库的脚本的文件。该解决方案的优点在于，更改脚本可能会有所不同，具体取决于目标数据库的状态。
不幸的是，如果您没有可用的“ DBPro”（再次考虑一下客户端站点），您将不得不使用VSDBCMD从架构文件生成更改脚本。尽管这行得通，但是如果Microsoft公开了VSDBCMD的API，那就太好了，因此可以创建一个GUI，以便非开发人员类型可以更轻松地执行，而不必使用命令行工具。
很难想象VS Team Database Edition将来不会获得其他功能，因此，假设您当然可以忍受该工具的当前缺点，那么押注MS可能并不是一场赌博。
,您不会像这样将源代码控制集成到数据库中。
它不是基于文件的。您的数据库由表，代码，数据，索引，统计信息，安全性等组成：这些都存在于系统表中。
而是复制+粘贴，请参阅我以前的答案...
RedGate SQL源代码管理适合我吗？
将SQL Server数据库对象公开为文件系统中的文件
我们或多或少地遵循Martin Fowler的“进化数据库设计”