转载

数据库版本管理最佳实践

数据库版本管理的难点

数据库管理员与应用开发者想必多少都经历过数据库版本管理的痛苦，随着团队规模、客户数量以及基础设规模的上升，管理工作的复杂度将呈几何次数上升。那么数据库的版本管理究竟有何与众不同之处，为何不能像普通的代码与服务器一样采取相同的管理方式呢？数据库与其它系统组件的不同之处有以下几点：

数据库中所存放的不仅是表数据，还有其它各种数据库对象，如表结构、索引、存储过程、角色、权限等等。这些数据库对象同样也需要进行版本管理，否则就有可能出现破坏性的错误。
对于应用程序的部署，可以使用自动化持续集成工具，甚至可以通过容器现实不可变基础设施。因为这些应用程序一旦部署之后，在下一次部署之前通常不会产生任何变化。但数据库中包含着大量实时的业务数据，数据表中的内容每时每刻都在变化，无法以类似于二进制文件替换的方式简单地部署变更。
数据库也可能具有外部依赖，例如在SQL Server中可以调用外部的SQL CLR程序集，对于这些依赖同样要进行版本管理。但目前在数据库领域还很少有类似于 npm 或 NuGet 这样的包管理工具能够进行方便地依赖管理。
数据库是一种集中化的资源，如果多个开发者同时提交的修改中有冲突，那么在实际运行变更脚本之前几乎无法检测到这种冲突的存在。

来自于EastBanc Technologies的Vladimir Khorikov近期发表了一篇博客文章，为读者介绍了一些他在数据库版本管理方面所采用的最佳实践。

最佳实践

最佳实践之一：将数据库和引用数据与代码一视同仁，也即是说它们也需要由版本控制系统进行管理。

Vladimir在这里特意强调了引用数据的重要性，这些数据是运行应用程序不可或缺的元数据，因此同样需要保存至版本控制系统中。

最佳实践之二：数据库Schema与引用数据的每一次变动都应进行显式的记录，也就是说，对于数据库的任何一次修改，都应当保存在一个独立的文件中。如果某个变更脚本会同时影响到Schema与引用数据，那么应当将这些变动保存在同一个脚本文件中。

数据库版本管理最佳实践

Vladimir认为，坚持遵守为每一次修改生成一个独立的脚本文件的做法非常有必要。如今有许多项目的做法是将数据库的Schema保存在版本控制系统中，也就是保存了当前数据库版本的一个快照。这种方式无法将不同的修改分别保存到不同的脚本文件中，此外，在引用数据表中的变动往往会被忽略。

目前已经有许多工具可以对数据库进行版本控制管理，例如Visual Studio中的数据库项目，以及Redgate的 SQL Source Control 。虽然这些工具在小型数据库项目的管理中十分便利，但在Vladimir看来，在大型项目中以自动生成脚本的方式管理数据库反而变成了一种负担。他将在今后的博客文章中继续介绍这种工具的使用与问题所在。

最佳实践之三：当变更脚本部署之后，确保它的不可变性。

在Vladimir看来，在独立的文件中保存变更的意义就在于对这些变更进行追踪，一旦更改了这些脚本的内容，也就失去了版本管理的意义。因此正确的做法是保持这些脚本不变，如果需要撤消其中的某些变更，就另行创建一个单独的撤消脚本。

最佳实践之四：所有的数据库Schema与引用数据只能通过执行变更脚本的方式进行更新，坚决抵制人为修改数据库的做法。

与上一条实践一样，一旦对数据库直接进行手动更新，版本管理就变成了一纸空谈。因此必须通过签入版本控制系统中的脚本对数据库进行更新。

最佳实践之五：项目中的每个开发者都应当分配一个自有的数据库实例。

这一实践尤其适合于在大型团队中使用，因为在这种环境中，开发者的数据库变更很可能会与他人的变更产生冲突。而如果每位开发者都能够在一个独立的实例中进行开发，那么这种冲突可以在合并时通过版本控制系统解决。不过这种情况应当只适用于自动生成变更脚本的工具，否则不同的开发者会使用不同的脚本文件保存变更操作，版本控制系统对于不同文件中的冲突一无所知。

Vladimir还建议为每个代码分支创建一个独立的数据库实例，当然这种做法取决于不同分支中的代码有多大的差别。这个实践在实际情况中可能会面临两种问题，一是如何修改配置信息，让开发者连接到不同的数据库，同时这种配置信息的变更不应签入版本库中。二是如果数据库信息非常庞大，在更新与分发时就非常耗时与占用磁盘空间。

最佳实践之六：将数据库的版本号也保存在数据库中。

Vladimir就经常在一张独立的表Settings中保存一个数值型的版本信息。如果这个系统是一种可分发的应用（即每个用户都对应着一个不同的版本），那么可通过它了解当前客户所使用的应用的版本。