sql - 向现有 SQL Server 数据库添加版本控制

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

6年前关闭。




Improve this question




我是开发团队的一员，目前正在使用一个没有任何源代码控制的数据库。我们使用 SQL Server 2008 R2，并且一直使用 SSMS 直接管理数据库。它现在有~340 个表和~1600 个存储过程，加上一些触发器和 View ，所以它不是一个小数据库。

我的目标是让数据库处于版本控制之下，所以我一直在阅读文章，比如 Scott Allen's series以及许多与 SO 相关的旧问题。但我仍然无法决定如何进行。

我的想法是在一个文件中编写数据库模式脚本，然后在一个文件中编写过程、触发器和 View 。然后在 Mercurial 下保留所有版本。但当然，团队的每个成员都可以访问 SSMS 并直接更改架构和过程，我们中的任何人都有可能忘记在版本化文件中复制这些更改。

有哪些更好的选择？而且，我是否忘记了任何值得进行源代码控制的元素？我最担心的是，我发现的大部分文献都解释了在创建新数据库时如何进行版本控制，但在它已经很旧且相对较大时没有解释。

Answer 1

一般流程

我们为特定版本创建基线(例如 v1.0 )。基线包括一个完整的模式创建脚本，以及从允许的先前版本升级的脚本(如果有的话)(稍后会详细介绍)。所以对于 v1.0 ，我们只有一个脚本:

baseline-v1.0.sql

从该基线开始，我们创建增量更改脚本，因为我们从之前的基线开始工作。这些脚本是以可重入的方式创建的，因此它们可以安全地运行多次(第一次只执行任何实际工作；有关如何操作的建议，请参阅下一段)。我们只是为每个更改脚本创建一个文件，其中包含基线名称和时间戳(我们称之为版本)。例如，假设我们在基线之后创建两个更改脚本。我们会有以下文件:

baseline-v1.0.sql (for creating new installations)
baseline-v1.0-201211071220.sql (created on Nov. 7, 2012 at 12:20 PM UTC)
baseline-v1.0-201211122019.sql (created on Nov. 12, 2012 at 8:00 PM UTC)

我们创建了一个 schema_version有两列的表: baseline和 version . baseline是一些标签(比如上面提到的 v1.0)，还有 version只是更改脚本创建时间的时间戳(我们选择这样做是因为创建任意版本号会产生烦人的管理开销，而时间戳很容易使用)。因此，在运行更改脚本之前，我们通过 baseline 查询来检查更改脚本是否已被应用。和 version .如果它已经存在，只需退出脚本或其他任何东西。否则，应用更改并插入 schema_version表以标记更改脚本已完成。

示例更改脚本:

-- Created by <developer> on Nov. 7, 2012 at 12:20 PM UTC
declare @schema_baseline varchar(10), @schema_version varchar(12)

set @schema_baseline = 'v1.0'
set @schema_version = '201211071210'

if exists (select 1 from schema_version where baseline = @schema_baseline and version = @schema_version = @schema_version) return 0

-- begin change script

-- place your schema changes here

-- end change script

insert into schema_version(@schema_baseline, @schema_version)

现在，当我们实际安装软件时，我们运行相关的 baseline脚本。当我们升级那个版本时，我们只是按顺序应用更改脚本。

当我们在产品开发阶段达到一个重要的里程碑时，我们会创建一个新的基线。因此，我们创建了一个新的基线脚本(同样，这是作为基线的数据库快照)，以及来自先前基线的升级脚本。所以假设我们有一个新的基线， v2.0 ，我们将有以下文件:

baseline-v2.0.sql (for creating new installations)
baseline-v2.0-upgrade-v1.0.sql (for upgrading from v1.0)

然后该过程继续。

我们如何应用更改

这些脚本都保存在源代码管理中。我们确实有一个工具可以打包这些文件并自动升级我们的支持和安装团队使用的数据库。该工具计算出目标数据库的当前基线，并询问用户是否希望升级到包中的基线。如果是，并且当前版本有有效的升级路径，则应用升级脚本，并更新 schema_version.baseline ，并从先前的基线中删除更改脚本的所有条目。如果数据库是新的，它将应用常规基线脚本。无论哪种方式，在达到基线后，它都会在事务中按顺序应用包中存在的基线中的所有更改脚本。如果特定更改脚本失败，它会回滚最后一组更改和错误。我们查看日志，修复任何问题，然后再次重新运行包。在这一点上，它应该只在最后一个成功的更改脚本处开始，从而节省时间。

自动化和差异工具

我们不允许差异工具直接升级生产数据库。只是太冒险了。当然，我们确实使用 diff 工具来帮助创建我们的升级和更改脚本，但是一旦我们有了它们，我们就会对它们进行梳理、按摩、测试等，然后根据上述规范创建升级或更改脚本.我们确实使用工具/shell 脚本来创建更改脚本文件并放置样板 schema_version检查。

注意事项

它实际上非常简单，而且效果很好。唯一真正变得棘手的是分支。在大多数情况下，分支处理得很好。如果我们需要一个特定分支工作的更改脚本，一旦我们将分支合并回来，它就会很好地折叠到主线中。没问题。当两个分支尝试做类似的事情时，或者一个分支依赖另一个分支时，就会变得棘手。不过，这主要是一个流程和规划问题。如果遇到这种情况，我们只需创建一个新的基线(比如 v2.1 )，然后相应地更新分支。

要记住的另一件事是，如果安装想要从一个基线升级到另一个基线，则在我们升级到新基线之前，它必须应用当前基线的所有未完成更改。换句话说，我们不会让安装直接从它们所在的位置跳到下一个基线(当然，除非它们已经处于当前基线的最新版本)。