数据库版本控制最佳实践

18-11-09 banq
         

最佳实践#1 :我们需要将数据库及其中的参考数据视为常规代码。 这意味着我们应该将其架构和参考数据存储在版本控制系统中。

请注意,此规则不仅包括数据库的模式,还包括其中的参考数据。 参考数据是运行应用程序所必需的数据。 例如,如果您有可能存在应用程序所依赖的所有客户类型的字典,则还应将其存储在源控制系统中。

最佳实践#2 :我们必须明确地存储数据库的模式和参考数据中的每个更改。 这意味着对于我们进行的每个修改,我们都应该创建一个包含更改的单独SQL脚本。 如果修改同时影响模式和参考数据,则它们应反映在单个脚本中。

遵守此规则是构建成功的数据库版本控制系统的重要部分。 许多项目将其数据库模式存储在源代码控制中,但通常只是最新数据库版本的快照。 其中的所有更改都由源控制系统本身跟踪,它们不会显式存储。 此外,通常不会跟踪参考数据的变化。

Visual Studio数据库项目等工具强调这种方法,并敦促程序员使用自动生成的升级脚本进行模式更新。 虽然这可能适用于小型项目,但在较大的项目中,使用自动生成的脚本跟踪数据库中的更改会成为负担。 

最佳实践#3 :每个SQL脚本文件在部署到生产环境或登台环境后必须是不可变的。

将更改存储在单独文件中的重点是能够跟踪每个文件。 当我们修改现有的SQL脚本时,我们会失去数据库版本控制最佳实践为我们提供的所有好处。 部署后保持脚本文件不可更改。 如果您需要调低已发布的更改,请为其创建单独的脚本。

最佳实践#4 :必须通过脚本实现数据库模式和参考数据中的所有更改。 它们都不能手动应用。

如果我们不通过脚本修改数据库,那么数据库版本控制的整个想法就变得毫无价值了,所以我们需要确保只通过我们创建的SQL脚本进行更改。

最佳实践#5 :团队中的每个开发人员都应拥有自己的数据库实例。

通常,团队从开发人员环境中的单个数据库开始。 这在开始时运作良好,但是当数据库变得足够大时,对它的同时修改变得越来越难,直到在某些时候停止工作。

程序员所做的改变往往是不兼容的,所以每个程序员都有一个单独的数据库实例来避免这种冲突是个好主意。 如果开发人员同时修改数据库模式的相关部分,则可以使用源控制系统解决此类冲突,就像C#/ Java / etc代码中的冲突一样。

此外,如果您的代码库有多个分支,则可能还需要为每个分支创建一个单独的数据库实例,具体取决于这些分支中的数据库的不同。

最佳实践#6 :数据库版本应存储在数据库本身中。 我通常倾向于创建一个名为Settings的单独表,并将版本保留在那里。 不要使用复杂的符号,如“xyz”作为版本号,只需使用一个整数。

这种方法有什么好处?

那么这些数据库版本控制最佳实践对我们有什么好处?

第一个也是最重要的优点是,当我们使用这种方法时,我们不再存在数据库模式不匹配的问题。 当然,如果我们完全遵守上述规则,自动升级到最新版本就可以完全解决它们。

当您没有单个生产数据库但每个客户端都有自己的数据库实例时,这尤其有用。 如果不采用适当的版本控制技术,在这种情况下管理数据库版本可能会变得很糟糕。

这些最佳实践提供的另一个好处是数据库更改的高度凝聚力 。 这意味着模式和参考数据中的每个显着修改都反映在一个地方,而不是分布在整个应用程序中。

SQL升级脚本还具有很高的内聚性,它们包含功能所需的每个数据库更改,因此很容易理解在数据库中进行了哪些修改以解锁特定功能。 将模式和数据更改保持在一个文件中相互关联也有很大帮助。

即使您从一开始就没有遵循它,本文中描述的方法也适用。 要将其付诸实践,您只需要创建一个初始脚本,其中包含您现在正在生产的数据库模式,并从该时刻开始逐步更改它。 当前版本就应该成为版本#1,您可以使用我们上面讨论的技术进一步移动。