为什么以及何时使用Liquibase？

我试图在堆栈溢出时搜索此问题，但找不到与此相关的任何问题。
我是新来的Liquibase，想知道

• 为什么Liquibase呢
• 什么时候应该Liquibase在项目中使用？

我知道这是将所有数据库更改都保留在一个地方，但是可以通过SQL在某个存储库系统中创建一个简单文件并随时间进行更新来完成类似的操作。

自我管理的模式创建文件和Liquibase（或其他模式迁移工具）之间的主要区别在于后者提供了模式更改日志。这是架构随时间变化的记录。它允许数据库设计人员指定架构中的更改并根据需要以编程方式升级或降级架构。

还有其他好处，例如：

• 数据库供应商独立性（这是有问题的，但他们会尝试）
• 自动化文件
• 数据库架构差异

一种替代工具是飞行通道。

您将在需要或需要自动管理模式更新而不会丢失数据时选择使用模式迁移工具。也就是说，您希望在将系统部署到长期存在的环境（例如客户站点或稳定的测试环境）之后，架构会发生变化。

在修改架构时，我已经看到liquibase在开发人员中建立了纪律。您只是无法去覆盖其他开发人员的更改并执行。相反，您可以创建自己的变更集并将其添加到要执行的变更序列的末尾。这也清楚地说明了何时以及由谁带来了什么变化。

一种非常“版本化”的模式维护方法。

对于初学者来说，它的确给人以“不必要的工作”的印象。

当您在开发，质量保证，生产中有多个数据库实例并且您想要一个工具来自动跟踪更改历史记录并智能地应用更改（应用当前模式和最终模式的差异）时，诸如liquibase或flyway之类的工具将非常有用。

当您的想法是数据库是事后的想法时，我相信Liquibase很棒。这种理念已导致生产中的大多数不良数据库-其中大多数是不良的。数据库的设计应具有整个业务系统的完整视图，而不是由每个都在各自的孤岛中工作的应用程序开发人员所组成。后一种方法会导致变通方法，数据规范化，表之间的关系不佳，业务区域重复以及客户在部署后由于其所引起的问题而讨厌的总体混乱，维护成本高的系统。如果设计一个数据库来准确反映业务关系，那么它的寿命将是最零碎地设计的数据库的5倍，并且可以达到其目的的5倍。

Liquibase本身不是问题，但是它使应用程序开发人员可以设计数据库。那就是问题所在。

我认为，如果您浏览以下文章http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html，为什么可以回答liquibase

如果仔细阅读，能够通过简单的mvn或CLI命令从较高的版本降级到较低的版本将非常有用，如果您将sql文件提交到GIT的方法将无法获得，因为那样您必须手动运行这些脚本，并且您也没有更改集，如：-谁做了更改作者等。

作为我的团队的DevOps，我希望将所有SQL文件放在一个位置，即放在我的SCM（源代码管理）中

同样在CI / CD阶段，如果同时创建数据库模式，则可以节省大量时间和资源。您不必再由其他人为该客户端管理数据库。

Flyway，Liquibase，EF等ORM有助于实现这一目标。