Why and when Liquibase?

问题:

I have tried to search this question on stack overflow but couldn't find any question for this. I am new on liquibase and wants to know why liquibase? And when exactly one should use liquibase in the project?

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

回答1:

The key differentiator between a self-managed schema create file and Liquibase (or other schema migration tools) 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 changes in schema & enables programmatic upgrade or downgrade of the schema on demand.

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.

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.

回答2:

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, 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.

A very "versioned" approach to schema maintainence.

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

回答3:

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.

回答4:

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 is not a problem in itself but it enables the practice that application developers design the database. THAT is the problem.