sql-server-2005 – 版本控制SQL Server？

发布时间：2020-12-12 06:29:50 所属栏目：MsSql教程来源：网络整理

导读：我的开发小组使用Visual Source Safe进行版本控制;这个选择最初是由于成本和与Visual Studio的紧密集成而产生的. 随着我们的存储库不断增长,Source Safe已经开始显示其局限性,我们正在考虑转向另一种解决方案.讨论的是Team Foundation Server,Subversion,Git

我的开发小组使用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的经验,并且可以为每个系统提供一些可靠的优点/缺点,以及如何实现它们.

解决方法

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

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

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

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

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

我们遇到的唯一不利点是确保开发人员遵守该流程.放牧猫是一个非常恰当的描述.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!