sql - 如何在 Liquibase 中对数据库架构的基线进行版本控制

Question

我目前正在评估我的组织如何利用 liquibase 作为数据库版本控制系统。

但是，我对于如何将 liquibase 理念融入我们当前的工作流程确实遇到困难:

目前，我们的应用程序的 CREATE 和初始填充 sql 脚本处于版本控制之下。一旦发生更改(例如新列)，程序员就会调整 CREATE 脚本并检查更改。由于应用程序代码和 SQL 脚本位于同一存储库中，因此数据库对象应始终与应用程序版本同步。

此外，对于每个版本，我们都会维护一个 ALTER... 语句列表，这些语句在客户升级我们的软件时使用(这种情况比从头开始安装更常见)。

因此，我们有两个世界 - 模式对象的当前版本(作为存储库中的 CREATE 语句)以及从版本 1 到版本 2 所需的操作列表(ALTER 语句)。

我喜欢的是架构对象的定义始终与软件的版本匹配，因为它们位于同一版本控制存储库中。

我不喜欢(因此寻找替代方案)的是我们必须做的双重工作。此外，由于该软件比新安装的软件更新得更多，因此 CREATE 语句更多的是文档，但很少应用于数据库。

我的理解是，liquibase 从基线开始，然后在小的变更集上运行。因此，我会检查一次基线，然后添加我的小更改集。

随着时间的推移，我可能会拥有一个包含大量更改集的旧基线。我假设我必须从旧基线+变更集中手动生成新基线，并从那里重新开始。这对我来说听起来相当令人困惑。我也不确定我的同事是否会看到与我们当前工作流程相比的好处。

你会推荐什么？

Answer 1

这只是我的意见，所以就这样吧。

Liquibase 的理念是，只要可以查询数据库以查看对其应用了哪些更改，就不需要您提到的基线，因此您必须定期生成新基线的假设是不正确的。

让我们比较一下您的流程与 Liquibase 流程的工作原理。

• 在您当前的系统中，正如您所说，开发人员必须维护两套 SQL 脚本，而您的测试人员必须确保它们是正确的。当用户安装时，您的安装程序必须检测它是否是全新安装并仅运行“创建”脚本。当安装程序检测到升级时，它必须采用不同的路径(可能使用一些复杂的逻辑)来确定要运行哪些更改脚本。您的组织必须维护执行升级逻辑的安装程序代码。

• 使用 Liquibase，开发人员只需创建数据库脚本的“更改”部分。对于新安装，运行所有 Liquibase 语句所需的时间可能比在当前系统中运行创建脚本所需的时间稍长，但好处是减少了重复，从而减少了错误。对于升级安装，Liquibase 通过查看已安装的数据库来确定哪些更改已到位，并且仅运行使数据库与正在安装的代码保持最新所需的更改。