Я попытался найти этот вопрос при переполнении стека, но не мог найти для этого никакого вопроса. Я новичок в ликбазе и хочу знать, почему ликбаза? А когда именно нужно использовать Liquibase в проекте?
Я знаю, что это сохранить все изменения базы данных в одном месте, но подобное можно сделать, создав простой файл sql в некоторой системе репозитория и продолжайте обновлять его со временем.
Ключевым отличием между файлом создания схемы с самостоятельным управлением и Liquibase (или другими инструментами миграции схемы) является то, что последний обеспечивает журнал изменений схемы. Это запись изменений схемы со временем. Это позволяет разработчику базы данных указывать изменения в схеме и позволяет программно обновлять или понижать версию схемы по требованию.
Есть и другие преимущества, такие как:
Одним из альтернативных инструментов является пролет.
Вы можете использовать инструмент миграции схемы, когда вам нужно или вам нужно автоматически управлять обновлениями схемы без потери данных. То есть вы ожидаете, что схема изменится после того, как ваша система будет развернута в долгоживущей среде, такой как сайт клиента или стабильная тестовая среда.
Я видел, как liquibase создает дисциплину среди разработчиков, когда дело доходит до модификации схемы. Вы просто не можете пойти и переписать другое изменение разработчика и выполнить. Вместо этого вы создаете свой собственный набор изменений и добавляете его в конец последовательности изменений, которые должны быть выполнены. Это также дает ясность в отношении того, какие изменения произошли, когда и кто их принес.
Очень "версионный" подход к сопровождению схемы.
Для начала это создает впечатление "ненужной работы".
Когда у вас есть несколько экземпляров базы данных в dev, qa, production и вы хотите иметь инструмент для автоматического отслеживания истории изменений и интеллектуального применения изменений (применение различий текущей схемы и окончательной схемы), такие инструменты, как liquibase или flyway, будут очень полезны,
Я думаю, почему на liquibase можно ответить, если вы прочитаете статью ниже http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html
Если вы внимательно ее прочитаете, то возможность перехода на более низкую версию с более высокой версии с помощью простых команд mvn или CLI будет очень полезной, чего вы не получите, если будете использовать подход, заключающийся в фиксации файла sql в GIT, потому что тогда вы необходимо вручную запустить эти сценарии, а также у вас нет набора изменений, таких как: - кто внес изменения и т.д.
Я только что начал с Liqubase, и я хочу узнать, какое преимущество будет иметь мой DDL, покрытый XML (в случае использования Liqubase) по сравнению с тем же DDL, покрытым какой-либо оболочкой, например без Liqubase, и выполненный из Git в DB?
Будучи разработчиком DevOps, я бы предпочел, чтобы все мои файлы SQL находились в одном месте, т.е. в моем SCM (управление исходным кодом)
Также во время фазы CI/CD, если схема БД создается вместе с ней, это экономит много времени и ресурсов. Вам не понадобится другой человек, управляющий вашей базой данных для этого клиента.
ORM как Flyway, Liquibase, EF и т.д. Помогает в достижении этого.
Я считаю, что Liquibase отличная, когда ваша философия заключается в том, что база данных является запоздалой. Эта философия вызвала большинство плохих баз данных в производстве - и большинство из них плохие. База данных должна быть спроектирована с полным представлением всей бизнес-системы, а не для разработчиков приложений, каждый из которых работает в своих силосах. Последний метод приводит к обходным ситуациям, денормализованным данным, плохим отношениям между таблицами, дублированию бизнес-областей и общей грязной системе с высоким уровнем обслуживания, которую клиент будет ненавидеть вскоре после развертывания из-за проблем, которые он вызывает. Если база данных предназначена для ТОЧНОГО отражения деловых отношений, ее срок службы будет в 5 раз длиннее и будет служить своей цели в 5 раз лучше, чем один, разработанный по частям, как, к сожалению, большинство из них.
Liquibase сама по себе не проблема, но она позволяет практике разработчиков приложений создавать базу данных. Это проблема.