sql-server-2005 - 对 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 数据库之上执行此操作。

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