版本化SQL Server？

Question

我的开发小组使用Visual Source Safe进行版本控制; 这个选择最初是由于成本和与Visual Studio的紧密集成而产生的.

随着我们的存储库的增长,Source Safe已经开始显示其局限性,我们正在考虑转向另一个解决方案.讨论的是Team Foundation Server,Subversion,Git和Mercurial.

我们主要是一个数据商店,因此我们的另一个主要因素是能够轻松地对SQL Server 2005/2008项目进行版本控制.这是使用Source Safe以及Team Foundation Server(与Microsoft SQL Server Management Studio集成)的好处之一.

我想知道是否有人有使用Subversion,Git或Mercurial版本化SQL Server的经验,并且可以为每个系统提供一些可靠的优点/缺点,以及如何实现它们.

Answer 1

我诚实的回答是,如果可以避免,请不要与数据库工具和SCM进行任何集成.尽可能使用文件系统.这是另一层整合,这将是一个痛苦.小型独立工具比庞然大物更好.

我们在以下庄园中一起使用Subversion和SQL 2005:

• 我们只使用TortoiseSVN.根本没有VS/SSMS集成.
• 我们有一个"自动化一切"的原则,所以我们从不依赖GUI工具来完成工作.
• 我们将所有脚本与代码一起保存在SVN中.代码,架构和脚本一起版本化.
• 模式更改按应用顺序编号,即000-create-table-users.sql.我们记下每个环境中部署的最大脚本编号.每个脚本都执行到下一个数据库r号的迁移.部署时,我们检查源并运行从最新版本号到最高编号的所有脚本.
• 任何非模式脚本(sprocs/views)都是幂等的(可以使用相同的结果执行任意次数).它们是通过我们编写的nant插件应用的.每次部署时都会替换它们.别忘了刷新你的意见!
• 我们使用NHibernate时尽可能避免使用任何脚本,因此无论如何脚本版本控制的问题都会减少.

从这个结构中,我们可以在任何重要的机器上的任何时间点重新创建环境和数据库.

我们不会将它用于单元测试 - 我们依赖于NHibernate模式生成在SQLite数据库之上执行此操作.

我们遇到的唯一不利点是确保开发人员坚持这个过程.放牧猫是一个非常恰当的描述.

Answer 2

恕我直言，Git 和 Mercurial 是唯一您应该考虑的，其他 2 个都太过时了。现代 SCM 应该像 git 一样对待分支。

有关 git 与 Mercurial 的比较，请参阅： http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/、http://www.russellbeattie.com/blog/distributed-revision-control-systems -git-vs-mercurial-vs-svn。

虽然我过去没有 SSMS SCM 集成的经验，但据我所知，提到的两个系统（除了 TFS）都没有经验。我不会称其为缺点 - 例如 git GUI 是一个非常方便的工具，您会发现它比这样的集成更令人愉快。至少这是我从 SVN（使用 Ankh 进行 VS 集成）迁移到 Git（根本没有集成）时的情况...