Можно попробовать подойти к задаче через
автоматическую генерацию миграций из базы, чтобы не переносить данные вручную в CSV и SQL.
Вот несколько подходов, которые могут помочь:
- Liquibase diff
Liquibase умеет сравнивать текущее состояние базы с эталонным snapshot или changelog (команды liquibase diff, generateChangeLog). Это может автоматически сгенерировать changesets. Не всегда идеально, особенно для данных, но может служить хорошей стартовой точкой.
- Скрипт дампа и автоформатирования
Написать утилиту, которая:
- выгружает актуальные записи (по дате или через служебную метку),
- форматирует результат построчно (для удобных диффов в Git),
- сохраняет в SQL или CSV с нужным форматированием,
- проверяет ошибки: зависимости, ключи, синтаксис и т. п.
- Служебное поле
change_id
Добавление такого поля в ключевые таблицы упростит группировку и экспорт связанных изменений. Это также упростит отладку и проверку связей.
- Проверки перед мержем
Автоматический pre-merge скрипт может:
- проверять, что ветка актуальна относительно master,
- валидировать синтаксис SQL и CSV,
- выявлять ошибки в зависимостях (foreign keys, отсутствие spec при наличии body и т. п.),
- проверять потенциальные конфликты по ключам в changesets.
- Dolt и Bytebase
Как уже писали выше, эти проекты позволяют рассматривать базу как репозиторий Git. Подход интересный, но требует серьёзной перестройки процессов. Внедрение возможно, если проект активно развивается и готов к архитектурным изменениям.
Если кратко: можно улучшить текущую схему с помощью автоматизации и валидации, либо двигаться в сторону Git-ориентированных решений, где изменения фиксируются на уровне базы, а не вручную.
