Liquibase的原因和时间？

Question

我试图在堆栈溢出时搜索这个问题但是找不到任何问题。我是liquibase的新手，想知道为什么liquibase？什么时候应该在项目中使用liquibase？

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

Answer 1

自我管理模式创建文件和Liquibase（或其他schema migration工具）之间的关键区别在于后者提供了模式更改日志。这是架构随时间变化的记录。它允许数据库设计者在schema＆amp; amp;中指定更改。支持按需编程升级或降级模式。

还有其他好处，例如：

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

另一种替代工具是flyway。

如果需要或需要自动管理架构更新而不丢失数据，则可以选择使用架构迁移工具。也就是说，您希望在将系统部署到长期环境（例如客户站点或稳定的测试环境）后更改架构。

Answer 2

我已经看到liquibase在开发人员修改架构时创建了纪律。你不能去覆盖其他开发人员的变更和执行。而是创建自己的变更集，将其添加到要执行的更改序列的末尾。这也清楚地说明了何时以及谁带来了变化。

一种非常“版本化”的架构维护方法。

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

Answer 3

如果您在dev，qa，production中有多个数据库实例，并且您希望拥有一个工具来自动跟踪更改历史记录并智能地应用更改（应用当前架构和最终架构的差异），liquibase或flyway等工具将会非常有用。

Answer 4

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

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

Answer 5

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

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

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

Answer 6

我相信当您的理念是数据库是事后的想法时，Liquibase很棒。这种理念导致生产中的大多数不良数据库 - 而且大多数都是坏的。应该设计一个数据库，其中包含整个业务系统的完整视图，而不是由每个在自己的孤岛中工作的应用程序开发人员拼凑而成。后一种方法导致解决方法，非规范化数据，表之间的关系差，业务区域重复，以及客户在部署后不久由于其引起的问题而讨厌的整体混乱，高维护成本系统。如果一个数据库的设计能够准确地反映出商业关系，那么它的生命周期将是其5倍，并且其服务目的将比以零散的方式设计好5倍，不幸的是大多数都是。

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