Контроль версий в базах данных — Сравнение Liquibase и Flyway

[SimSonic]

Хотелось бы и ложку дёгтя :)
В большой команде, если используется Flyway, приходится придумывать костыли в виде сообщения в чатике "я занял номер миграции 187", либо использовать флаг outOfOrder, и всё равно на ревью могут выскочить одинаковые номера и придется править.
У ликвибейза xml многословен, но у yaml и других вариантов нет автодополнения.

[SimSonic]

Спасибо за лайфхак!) Сейчас на проекте юзаю lb, но для себя выработал форматирование: каждый атрибут любого тёща, начиная со второго, с новой строки, чтобы преобразовать код из 2мерного в 1мерный по вертикали.
Да, часто видел, что пишут в нём только sql миграции, по-моему это ну такое, местами сомнительное. Почему тогда не flyway?)

[mih-kopylov]

Ещё один способ обойти ограничение — использовать дату вместо порядкового номера версии.
Например, V20210103_0530__Change_description.sql

[Bosonshik]

Видел «решение» для большой команды в виде простого сервиса раздачи уникального растущего ключа. Пишется на чем угодно за вечер. Бот для чатика наверное еще пару вечеров может занять максимум.

outOfOrder жизненно необходимая вещь, когда в реп коммитят ежедневно 20+ человек.

[shmelev-1987]

Для MSSQL предпочитаю использовать связку:
1) отдельный SQL файл на каждый объект БД, где обязательно учитываются возможные проверки существования объектов
2) систему контроля версий (Git)
3) командный файл для наката изменений (BAT файл)
Подробно об этом написано в статье Ведение разработки БД. Шаблоны создания/изменения объектов MSSQL

[shmelev-1987]

1) Не требуется изучать, устанавливать и настраивать сторонние компоненты (Liquibase, Flyway и др.). Все работает из коробки (с помощью sqlcmd и bcp).
2) Удобно отслеживать изменения объектов БД в Git, так как история одна (на каждый объект БД). В случае с liquibase, объект будет изменяться в каждой версии и поиск изменений усложняется.
3) При связке Liquibase и MSSQL обнаруживал баг, связанный с выводом комментариев через PRINT. Первый PRINT выводил нормально, а последующие не выводил. Наверняка, есть и другие баги.

[shmelev-1987]

Цитата из статьи:
3) Если изменения касаются данных, то такие изменения ведутся в отдельном файле "CommonChanges (version 000).sql", который создается на каждое обновление БД
Все важные изменения в скрипте нужно выполнять с использованием транзакций.

[Bosonshik]

А как обеспечивается правильный порядок создания объектов?
Простой пример из вашей статьи
-- Создать FOREIGN KEY, если его не существует
if not exists (select * from sys.foreign_keys where object_id = OBJECT_ID(N'dbo.FK_TableName_FieldName1') AND parent_object_id = OBJECT_ID(N'dbo.TableName'))
ALTER TABLE dbo.TableName WITH CHECK ADD CONSTRAINT FK_TableName_FieldName1 FOREIGN KEY(FieldName1)
REFERENCES dbo.ReferenceTableName (RefFieldName)
GO
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'dbo.FK_TableName_FieldName1') AND parent_object_id = OBJECT_ID(N'dbo.TableName'))
ALTER TABLE dbo.TableName CHECK CONSTRAINT FK_TableName_FieldName1
GO
Нет проверки что существует dbo.ReferenceTableName, но как обеспечивается создание dbo.ReferenceTableName ДО dbo.TableName не написано :(

И как быть с взаимозависимыми таблицами? Когда есть условное table1.link --> table2.pk и table2.backlink -> table1.pk

[shmelev-1987]

FOREIGN KEY нужно создавать отдельными файлами. Перед созданием FOREIGN KEY, естественно, нужно выполнить создание таблицы.
Порядок выполнения задается в BAT'нике.

[shmelev-1987]

1) Если количество изменений очень большое, то ваш репозиторий будет сильно расти и файлов будет в разы больше
2) При возникновении бага, легко отследить в каком коммите была допущена ошибка (это ключевой пункт в выборе по объектного изменения)
3) Легко отслеживать новые объекты в репозитории
4) Я себя приучил к тому, чтобы делать один коммит, когда функционал завершен. Если функционал не завершен, не коммичу. Поэтому в истории Git можно быстро понять какие объекты изменились в одном коммите.

P.S.: В большом проекте, для удобства, я всегда веду отдельный текстовый файл с описанием всех изменений (что-то вроде WhatsNew). Это помогает при поиске проблем и дает другим участникам команды быстрее войти в проект и понять хронологию развития.

[shmelev-1987]

Я ни в коем случае не принуждаю использовать мой подход. Я работаю так, как мне удобно и описал этот подход в статье. В Liquibase все описывается в XML формате, это можно рассматривать как плюс (если БД нужно поддерживать в нескольких СУБД) и как минусы:
1) Я не понимаю, зачем мне описывать XML в Liquibase, который будет непонятно как преобразовывать его в SQL, если сразу можно написать этот SQL запрос, вставить в него транзакции, предусмотреть все опции, хинты, проверки и т.д.
2) Отладка SQL запроса намного легче без использования сторонних библиотек

[shmelev-1987]

Попробуйте написать SQL запрос с использованием условия > (больше) или < (меньше) внутри XML.
В XML он начнет ругаться, что это системный символ и вам нужно будет при отладке заменять символы "& gt;" на > и "& lt;" на <. Разве это удобно?
Чтобы этого избежать, Вам нужно будет вести SQL файлы отдельно от XML.

[Bosonshik]

Подскажите пожалуйста можно ли в этих системах организовать:
— любые проверки до начала работы инкрементальных скриптов? Например: на наличие нужных расширений постгреса или на отсутствие активных сессий.
— действия, которые должны выполняться после каждого обновления?.. Например перекомпиляция пакетов (oracle), включение планировщиков.

И если можно, то как?

[SimSonic]

Справедливости ради, Java-имплементации миграций есть у обоих инструментов.

[Bosonshik]

Спасибо. Callbacks очень похоже на то, что решает указанные мною проблемы.