Чем плохи версионные миграции для SQL-like БД?

А какие у тебя проблемы?

Для каждого изменения накопилось уже пара десятков файлов с миграциями. Чем это грозит?

В перспективе, лет через 180 из-за накопившегося огромного количества мелких мелких файлов у тебя закончатся inodes в файловой системе и работа будет полностью парализована.

Понятно). Т.е. ничего страшного в количестве файлов миграции, в сущности, нет. Спасибо.

Не у всех же ФС такая проблема. Опять гадаем?

Можно наткнуться на необновлённую версию, особенно если это много где используется. IMHO нужно делать так:

1. Ввести номера версий для структуры бд и для клиентского кода. Просто int, не нужно усложнять себе жизнь.

2. В бд хранить версию самой бд и минимальную необходимую версию клиентского кода. В клиентском коде хранить его версию и минимальную необходимую версию бд. Клиент в начале работы проверяет версии и при необходимости ругается. Если известны максимальные совместимые версии, их легко добавить.

3. Отдельная софтина для обновлений бд. Безнадёжно устаревшие изменения можно выпиливать.

Люто-бешено плюсую анонимуса. Плюс к тому: каждая миграция должна мигрировать с одного точно определённого int-а на int+1. И ругаться, если ей дают ненадлежащую по версии базу.

Безнадёжно устаревшие не выпиливать, а складывать в архив.

Просто int, не нужно усложнять себе жизнь.

Безнадёжно устаревшие изменения можно выпиливать.

Нельзя. С простоинтом. А вот ежели принять за соглашение, что каждый минорный релиз включает все предыдущие правки, то тогда не придётся таскать всю историю правок со всемён Ивана Грозного. Но это уже не простоинт.

Да ничем не грозит, всё правильно делаешь. Когда-то делали одну софтину на джанге, которую клиенты сами ставили на свой сервак. Миграций за годы накопилось больше сотни. Основные грабли:

- (Очевидное) в миграциях бывают баги, которые ведут к потерям данных или оставляют базу в состоянии раком. Это очень неприятно. Поэтому код миграций должен быть максимально тупым и простым. Алсо нужны тесты.

- Разок напоролись по глупости: код миграции импортировал какие-то классы и функции из других модулей. Потом проект развивался, те классы и функции рефакторились, и старые миграции однажды сломались. Мораль: код миграции должен быть полностью самодостаточным. Весь используемый код из других модулей нужно тупо скопипастить в код миграции, а не импортировать. Чтобы в миграции осталась ТЕКУЩЯЯ ВЕРСИЯ НА ТОТ МОМЕНТ. Как бы душа этому не противилась. Алсо писать тесты.

- Недо-СУБД типа MySQL не умеют откатывать изменения схемы БД при откате транзакций. Если миграция завершится с ошибкой, кому-то придётся разгребать вручную, переименовывать колонки обратно и т. д. Мораль: не юзать недо-СУБД либо страдать.

- Первоначальная инициализация БД. Есть два способа. 1) Последовательно применить все 200 миграций к пустой базе. Надёжно, но долго. 2) Поддерживать отдельный код для инициализации БД с нуля. Эффективно, но если база развесистая и кода много, обязательно забудешь о какой-нибудь мелочи. В итоге миграции будут давать одну базу, а инициализация с нуля - другую. Что хуже, состояние базы может зависеть от того, какой версии софта она была создана. Велком таинственные глюки. Так эту проблему для себя и не решили, тупо накатывали все 200 миграций, занимало больше минуты. Если кто-то знает более хорошее решение, делитесь.

Это общие рекомендации, у ТС вопрос по большому количеству миграций.

Кстати, вот вспомнил из нашей практики (вряд ли это касается ТС, но все же). Чем больше количество изменений в схеме БД, тем дольше время наката, соответственно, технологическое окно, в которое клиент обновляет ПО, должно быть достаточно, чтобы успеть обновиться. В нашем случае это привело к определенной процедуре обновления ПО (с особыми требованиями к миграциям схемы БД и НСИ).

код миграции должен быть полностью самодостаточным

Очень полезное замечание.

кому-то придётся разгребать вручную

Надеюсь, это было написано про среду разработки. Такую миграцию на боевой БД никто в здравом уме запускать не будет.

https://en.wikipedia.org/wiki/Schema_migration#Available_Tools