为什么? 什么时候？

自管理的模式创建文件与 Liquibase (或其他 模式迁移工具)之间的关键区别在于后者提供了模式更改日志。这是模式随时间变化的记录。它允许数据库设计人员在模式中指定 改变，并允许根据需要对模式进行编程升级或降级。

还有其他好处，例如:

• 数据库供应商独立性(这是值得怀疑的，但他们会尝试)
• 自动化文档
• 数据库模式不同

一种替代工具是 飞行路线。

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

我已经看到当涉及到修改模式时，在开发人员之间建立了规则。您只是不能覆盖其他开发人员的更改并执行。相反，您可以创建自己的变更集，并将其添加到要执行的变更序列的末尾。这也清楚地说明了什么时候发生了什么变化，以及谁带来了变化。

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

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

I believe Liquibase is great when your philosophy is that the database is an afterthought. This philosophy has caused the majority of bad databases in production - and most of them are bad. A database should be designed with a full view of the entire business system, not in pieced by application developers each working in their own silos. The latter method results in work-arounds, denormalized data, poor relationships between tables, duplication of business areas, and an overall messy, high-maintenance-cost system that the client will hate shortly after deployment due to the problems it causes. If a database is designed to ACCURATELY reflect business relationships, its lifespan will be 5 times as long and will serve its purpose 5 times better than one designed in a piecemeal fashion as unfortunately most are.

Liquibase 本身并不是一个问题，但它支持应用程序开发人员设计数据库的实践。这就是问题所在。

When you have multiple database instances in dev, qa, production and you want to have a tool to automatically track the change history and apply changes intelligently(apply the diff of current schema and final schema), tools like liquibase or flyway will be very useful.

我认为如果你通读下面的文章，你就会明白为什么液基是可以回答的 Http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html

If you read it carefully the ability to downgrade to a lower version from a higher version with help of simple mvn or CLI commands is very useful which you don't get if you go through the approach of committing your sql file into GIT because then you have to manually run those scripts and also you dont have the change set like :- who did the changes author ,etc.

作为我的团队中的 DevOps 人员，我希望将所有 SQL 文件放在一个地方，即。在我的 SCM (源代码管理)

同样在 线人/CD 阶段，如果 DB 模式与它一起被创建，它将节省大量的时间和资源。您不必让另一个人为该客户机管理您的数据库。

ORM like Flyway, Liquibase, EF etc. helps In achieving this.

在观察了液体基地在几个月内被并入一个中型到大型项目之后，我提出了这样的观点: 开发人员必须为液体基地服务，而不是相反。我理解用例，但是在我们的开发过程中没有看到任何质量上的改进。我们的现实是，Liquibase 最大的问题是构建错误，这让我们的开发团队陷入困境。小的改变会引起大的头痛。我不建议使用它。

我认为在这个话题上加上这个概念是好的 进化数据库设计

在过去的十年里，我们开发和完善了许多 techniques that allow a database design to evolve as an application 这是敏捷方法学的一个非常重要的能力。 这些技术依赖于应用持续集成和自动化 重构到数据库开发，同时结束 DBA 和应用程序开发人员之间的合作 在绿色领域从事预生产和发布系统的工作 项目以及遗留系统。

在这里，你是马丁福勒的进化 https://martinfowler.com/articles/evodb.html的参考

这是一种不同的方法，如何创建一个设计数据库 这就是为什么液体基地和 Flyway。