database - 数据库和 “branch”

Question

我们目前正在开发使用数据库的应用程序。

每次我们更新数据库结构时，都必须提供一个脚本来将数据库从以前的版本更新到当前版本。

因此，数据库当前有一个编号，该编号为我们提供了当前版本，然后当我们要使用“旧”数据库时，我们的软件会进行更新。

我们遇到的问题是当我们有分支机构时:

当我们创建一个新的重要功能时，该功能将不适用于用户(且不包含在发行版中)，我们将创建一个分支。

主分支(主干)将定期合并，以确保创建早午餐具有最新的错误更正。

这是一些例证:

问题出在我们的更新脚本上。它们从以前的版本更新到当前版本，然后更新数据库的版本号。

想象一下，创建分支时我们具有DB版本17。

然后，我们进行分支，并在Trunk DB上进行更改。数据库现在具有版本18。

然后，在分支上进行数据库更改。因为我们知道已经有了新版本“18”，所以我们创建版本19和更新程序18-> 19。

然后，干线在分支上合并。

此时此刻，我们可能会有一些永远不会运行的更新程序。

如果有人在合并之前更新了他的数据库，则他的数据库将被标记为具有版本19，更新17-> 18将永远不会完成。

我们想要更改此行为，但找不到以下方法:

我们的约束是:

我们无法在同一分支

上进行所有更改

有时我们不仅有2个分支，而且我们只能从中继线合并到feature分支，直到功能完成

我们如何确保数据库分支之间的连续性？

Answer 1

我认为最简单的方法是使用Ruby-on-rails方法。每个数据库更改都是一个单独的脚本文件，无论大小如何。每个脚本文件都有编号，并且在进行升级时，只需从数据库当前编号到最后一个编号运行每个脚本即可。

实际上，这意味着您的数据库版本系统不再是v18到v19，而是开始是v18.0到v18.01，然后是v18.02，等等。向客户发布的内容可能会汇总到一个大型v19升级脚本中，但随着您的发展，您将进行许多许多小的升级。

您必须对其稍作修改，以使其适用于您的系统，每个脚本都必须在合并到分支中时重新编号，或者必须确保升级脚本不只是跟踪上一个升级号，而是跟踪每个升级编号，因此随着脚本的合并，缺失的漏洞仍将得到填补。

在创建发布标签(首先在行李箱上)时，您还必须将这些小的升级汇总到下一个主要号码中，以使一切保持理智。

编辑:所以从根本上讲，您首先要摆脱使用升级脚本在版本之间进行转换的想法。例如，如果您从一个表开始，并且主干添加了A列，而分支又添加了B列，那么您将主干合并到分支中-您实际上不能将两者都“升级”到该版本，除非分支的版本号始终大于中继的升级脚本，如果您随后将中继合并到分支，该脚本将不起作用。因此，您必须取消适用于开发分支的“版本”的想法。唯一的办法就是独立更新每个更改，并分别跟踪每个更改。然后，您可以说您需要“最后一个主版本加上colA和colB”(诚然，如果合并主干，则可以从主干中获取当前的主版本，无论是v18还是v19，但仍需要单独应用每个分支更新) 。

因此，您从DB v18的主干开始。分支并进行更改。然后，您稍后合并主干，数据库位于v19。您先前的分支更改仍然需要应用(或者应该已经应用，但是如果您重新创建数据库，则可能需要编写其中包含所有分支更改的分支更新脚本)。请注意，分支根本没有“v20”版本号，并且分支更改没有像在主干上那样对单个更新脚本进行。如果愿意，您可以将在分支上所做的这些更改添加为单个脚本(或1个“自上次中继合并以来”更改的脚本)或许多小的脚本。
分支完成后，最后一个任务是将对分支所做的所有数据库更改都带到一个脚本中，然后将其应用到主升级程序中；当该脚本合并到主干中时，该脚本将合并到当前的升级脚本和数据库版本号增加。

有一种可能对您有用的替代方法，但是当您尝试使用数据更新数据库时，我发现它有点不稳定，有时它只是无法进行更新，因此必须擦除并重新创建数据库(公平地说，如果我当时使用SQL脚本，可能会发生这种情况)。那就是使用Visual Studio数据库项目。这会将模式的每个部分存储为一个文件，因此每个表将有1个脚本。这些将被Visual Studio自身隐藏，向您显示设计师而不是脚本，但它们将作为文件存储在版本控制中。 VS可以部署该项目，并尝试升级您的数据库(如果已存在)。注意这些选项，许多默认值都说“拖放并创建”，而不是使用alter来更新现有表。

这些项目可以生成(主要是机器可读的)SQL脚本以进行部署，我们过去曾生成这些脚本并将其交付给不使用VS且仅接受SQL的DBA团队。

最后，还有Roundhouse，这不是我用过的东西，但它可能会帮助您成为新的升级程序“脚本”。它是一个免费项目，而且我阅读了它比VS DB项目更强大，更易于使用。它是一个数据库版本控制和变更管理工具，与VS集成，并使用SQL脚本。