Sql 如何在Liquibase中控制DB模式的基线

我目前正在评估我的组织如何使用liquibase作为DB版本控制系统

然而，我确实难以理解liquibase理念如何融入我们当前的工作流程：

目前，我们有版本控制下的应用程序的创建和初始填充sql脚本。一旦有更改（例如新列），程序员就会调整创建脚本并检查中的更改。由于应用程序代码和SQL脚本位于同一存储库中，因此DB对象应始终与应用程序版本同步

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

因此，我们有两个世界——当前版本的模式对象作为存储库中的CREATE语句，加上从版本1到版本2（ALTER语句）所需的操作列表

我喜欢的是模式对象的定义总是与软件的版本相匹配，因为它们位于同一版本控制存储库中

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

我所理解的是，liquibase从一个基线开始，然后在小的变更集上运行。因此，我会先签入基线，然后添加我的小更改集

随着时间的推移，我可能会有一个有很多变更集的旧基线。我假设我必须从旧的基线+变更集手动生成一个新的基线，然后再从那里开始。这听起来让我很困惑。我也不确定与我们当前的工作流程相比，我的同事是否会看到这些好处

---

你有什么建议吗？

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

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

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

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

---

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

---

我们的安装/升级过程甚至不那么复杂-这是一个高度手动的过程。当你说不需要基线时——你会如何将某个版本级别的程序源代码与所需的数据库对象连接起来？就我个人而言，我会将程序源代码和Liquibase更改日志保存在同一个源代码控制系统中，并在创建任何可分发工件时（zip文件、安装程序等）我会将它们捆绑在一起。感谢您的快速回答和最好的回答。“对于新安装，运行所有Liquibase语句可能需要稍长的时间”我想知道我们在这里讨论的时间还有多久。我想的是一个有数百个表的系统，它在不断发展。另外，一个新的安装可能需要迁移数百万条记录。一种方法是删除索引，然后在数据到位后重新构建索引。我想知道liquibase如何处理scenarios是这样的吗？我们目前正在进行一些性能评测，所以我有一些这样的数据。对于在Oracle 11上新安装一个包含13000个表（和许多其他对象）的架构，使用SQLPlus应用原始SQL和使用Liquibase进行部署之间的时间差<1%。两种方法都需要大约30分钟。