我目前正在评估我的组织如何将liquibase用作数据库版本系统。
但是，我对liquibase哲学如何适应我们当前的工作流程确实存在困难：
目前我们在版本控制下有我们的应用程序的CREATE和初始填充sql脚本。一旦发生更改（例如新列），程序员就会调整CREATE脚本并检查更改。由于应用程序代码和SQL脚本位于同一存储库中，因此数据库对象应始终与应用程序版本同步。
此外，对于每个版本，我们都会保留一份ALTER ...语句列表，这些语句在客户升级我们的软件时使用（更常见的情况是从头开始安装）。
所以我们有两个世界 - 当前版本的模式对象作为存储库中的CREATE语句，以及从版本1到2（ALTER语句）的必要操作列表。
我喜欢的是，架构对象的定义总是与软件版本匹配，因为它们位于相同的版本控制存储库中。
我不喜欢（因此寻找替代方案）是我们必须做的双重工作。此外，由于软件比新安装的更新，因此CREATE语句更多的是文档，但很少应用于数据库。
我理解的是，liquibase以基线开始，然后在小变更集上运行。所以我会检查基线，然后添加我的小变更集。
随着时间的推移，我可能会有一个包含大量更改集的旧基线。我假设我必须从旧基线+变更集中手动生成新基线，然后再从那里开始。这对我来说听起来很混乱。我也不确定我的同事是否会看到与我们当前工作流程相比的好处。
你会推荐什么？
答案 0 :(得分：0)
这只是我的意见，所以就这样吧。
Liquibase的理念是，您不需要提到的基线，只要可以查询数据库以查看已对其应用了哪些更改，因此您必须定期生成新基线的假设是不正确的。
让我们比较您的流程如何与Liquibase流程相比。
在您当前的系统中，正如您所说，开发人员必须维护两组SQL脚本，并且您的测试人员必须确保它们是正确的。用户安装时，安装程序必须检测它是否是干净安装并仅运行“创建”脚本。当安装程序检测到升级时，它必须采用不同的路径（可能使用某些复杂的逻辑）来确定要运行哪个更改脚本。您的组织必须维护执行升级逻辑的安装程序代码。
使用Liquibase，开发人员只会创建数据库脚本的“alter”部分。对于新安装，运行所有Liquibase语句可能需要比在当前系统中运行创建脚本所花费的时间更长的时间，但好处是减少重复并因此减少错误。对于升级安装，Liquibase通过查看已安装的数据库确定了哪些更改，并且仅运行使数据库与正在安装的代码保持同步所需的更改。