Комментарии 35
Пару недель назад внедрял миграции для баз данных. Смотрел на Liquidbase и flywaydb. Выбрали 2й, потому что он понятнее — работает с sql скриптами а не абстракциями. Но даже несмотря на всю простоту, внедрение в команде идёт со скрипом. Пару недель был переходный период когда можно было писать скрипты и для ручного запуска и для автоматического. Команда всё равно выбирала привычный ручной способ. Хотя, вся разница была в том как назвать скрипт и куда положить. Ну и небольшой howto нужно было прочитать.
Я это к тому, что для того чтобы освоиться с liquibase придётся потратить больше времени.
stackoverflow.com/questions/37385823/liquibase-vs-flyway-which-one-to-use
С Liquibase я работал пару лет назад. Liquibase мощнее, но и сложнее в освоении.
Из преимуществ Liquibase (о которых я знаю):
- независим от базы/диалекта
- умеет dry-run. Т.е. можно посмотреть какие sql-ы будут сгенерированы
- умеет rollback (при условии, что описаны сценарии для rollback-а)
Из минусов: - сложнее в освоении, настройке
- формат описания changeset-ов — xml. У меня был опыт — когда все changeset-ы были описаны в одном большом файле. Разруливать merge конфликты, конфликты версий при работе в большой распределённой команде было сомнительным удовольствием.
Не все так однозначно. Но вводить liquibase в команду даже из 10 человек я не рискнул бы без острой необходимости именно в liquibase-овских фишках.
Абстракция — это описание changeset-a в чистом xml. SQL обёрнутый в тэг — это не абстракция, это извращение. =)
Я ничего не имею против SQLа. Sql-ы в отдельных файлах — на здоровье. А Sql-ы внутри xml тэгов я считаю извращением. Когда ты один пишешь, пиши как хочешь. Но когда так пишет целая команда, то разобраться в том, к чему этот sql был написан (особенно если это pl/sql) проще когда sql отдельно, а xml отдельно.
Преимущества абстракций liquibase это:
- независимость (теоретически) от базы, liquibase генерит нужный sql код для конкретной базы. "Теоретическая" — потому, что такого требования часто нет, да и периодически все равно требуется что-то делать чистым sql, что уже ломает автоматическую совместимость
- возможность автоматического rollback, для большинство вещей типа создания таблиц, ключей и т.п. liquibase может автоматически создать "обратную" операцию и откатить изменения. Не то, чтобы их сложно было написать в SQL, но все же
Работает,
просто создаете sql файлы с данными и запускаете их.
Как вы организуете эти файлы под разные энвайронменты — это уже на что фантазии хватит.
Можно просто разные наборы данных иметь, а можно для test подготовить sql который будет править/расширять dev данные.
Я считаю очень удобными миграции в yii2. PDO, используемый в фреймворке отлично работает с большинством бд. Поддерживается как чистый sql, так и абстракции. Применяются только новые миграции. В общем, если просто установить php с pdo, можно пользоваться.
Liquibase: пример автоматизированного наката изменений на реляционную БД на примере Oracle HR Sample Schema