database 为什么以及何时 Liquibase？

Why and when Liquibase?

提问by Shakeel Shahzad

I have tried to search this question on stack overflow but couldn't find any question for this.
I am new on Liquibaseand wants to know

我试图在堆栈溢出上搜索这个问题，但找不到任何问题。
我是新来的Liquibase，想知道

• Why Liquibase?
• When exactly one should use Liquibasein the project?

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

I know that this is to keep all database changesin one place but the similar can be done by creating a simple SQLfiles in some repository system and keep updating it with time.

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

采纳答案by Synesso

The key differentiator between a self-managed schema create file and Liquibase (or other schema migrationtools) is that the latter provides a schema changelog. This is a record of the schema changes over time. It allows the database designer to specify changesin schema & enables programmatic upgrade or downgrade of the schema on demand.

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

There are other benefits, such as:

还有其他好处，例如：

• Database vendor independence (this is questionable, but they try)
• automated documentation
• database schema diffs

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

One alternative tool is flyway.

一种替代工具是flyway。

You would choose to use a schema migration tool when you want or need to automatically manage schema updates without losing data. That is, you expect the schema to change after your system has been deployed to a long-lived environment such as a customer site or stable test environment.

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

回答by iCrus

I have seen liquibase create discipline among the developers when it comes to modifying schema. You just can't go and overwrite other developer's change and execute . Instead, you create your own changeset and add it to the end of sequence of changes to be executed. This also brings in clarity on what change came when and who brought it.

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

A very "versioned" approach to schema maintainence.

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

For starters, it does give an impression of "unnecessary work" though.

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

回答by Ted Xu

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.

当你在 dev、qa、production 中有多个数据库实例，并且你想要一个工具来自动跟踪更改历史并智能地应用更改（应用当前模式和最终模式的差异），像 liquibase 或 flyway 这样的工具将非常有用.

回答by Shikhar Chaudhary

I think Why liquibase can be answered if you go through the below article http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html

我认为如果你通过下面的文章http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html可以回答为什么 liquibase

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.

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

回答by Bob Barry

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 很棒，因为您的理念是数据库是事后的想法。这种哲学导致了生产中的大多数坏数据库 - 其中大多数都是坏的。数据库的设计应该具有整个业务系统的完整视图，而不是由每个在自己的孤岛中工作的应用程序开发人员拼凑而成。后一种方法会导致变通方法、非规范化数据、表之间的不良关系、业务区域的重复以及整体凌乱、高维护成本的系统，由于其导致的问题，客户在部署后不久就会讨厌该系统。如果数据库旨在准确反映业务关系，那么它的生命周期将是其寿命的 5 倍，并且比以零碎方式设计的数据库（不幸的是大多数情况）更好地实现其目的 5 倍。

Liquibase is not a problem in itself but it enables the practice that application developers design the database. THAT is the problem.

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

回答by Sloka Roy

Being DevOps Person of my team I would prefer to have all my SQL files at one place i.e. In my SCM (Source Code Management)

作为我团队的 DevOps 人员，我更愿意将所有 SQL 文件放在一个地方，即在我的 SCM（源代码管理）中

Also during CI/CD phase, If the DB Schema gets created along with it, It saves a lot of time and resources. You wouldn't have to have another person managing your database for that client.

同样在CI/ CD 阶段，如果 DB Schema 随之创建，它会节省大量时间和资源。您不必让另一个人为该客户管理您的数据库。

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

像 Flyway、Liquibase、EF 等 ORM 有助于实现这一点。