Почему и когда при?

Я видел, как liquibase создает дисциплину среди разработчиков, когда речь заходит об изменении схемы. Вы просто не можете пойти и перезаписать изменения другого разработчика и выполнить их. Вместо этого вы создаете свой собственный набор изменений, добавляете его в конец последовательности выполняемых изменений. Это также вносит ясность в то, какие изменения произошли, когда и кто их принес.

Очень "версионный" подход к сопровождению схемы.

Для начала, это действительно производит впечатление "ненужной работы".

Когда у вас есть несколько экземпляров базы данных в dev, qa, production, и вы хотите иметь инструмент для автоматического отслеживания истории изменений и разумного применения изменений(применить разницу текущей схемы и окончательной схемы), такие инструменты, как liquibase или flyway, будут очень полезны.

Я считаю, что Liquibase-это здорово, когда ваша философия заключается в том, что база данных-это запоздалая мысль. Эта философия вызвала большинство плохих баз данных в производстве - и большинство из них плохие. База данных должна быть разработана с полным представлением всей бизнес-системы, а не по частям разработчиками приложений, каждый из которых работает в своих собственных бункерах. Последний метод приводит к обходным путям, денормализованным данным, плохим связям между таблицами, дублированию бизнес-областей и общему грязная, дорогостоящая в обслуживании система, которую клиент возненавидит вскоре после развертывания из-за проблем, которые она вызывает. Если база данных спроектирована так, чтобы точно отражать деловые отношения, ее срок службы будет в 5 раз дольше и будет служить своей цели в 5 раз лучше, чем та, которая разрабатывается по частям, как, к сожалению, большинство из них.

Liquibase не является проблемой сама по себе, но она позволяет разработчикам приложений разрабатывать базу данных. Вот в чем проблема.