Ответ.

История вопроса
Работа над крупными проектами требует, чтобы структура базы данных развивалась параллельно с кодом приложения. Без программного контроля версий изменений схемы (добавления, удаления и изменения таблиц, индексов, ключей) команда быстро теряет синхронность, возрастает риск потери изменений, сбоя миграций и усложняется откат или воспроизведение багов.

Проблема
Традиционный подход — ручное изменение БД через SQL-скрипты — приводит к неявному порядку выполнения изменений, сложностям в откате, нестыковкам версий между окружениями (dev, test, prod). Без общего инструмента для хранения миграций сложно понять, кто, когда и зачем изменил схему.

Решение
Для этой задачи используются системы миграций схемы и практики database versioning. Применение инструментов (например, Liquibase, Flyway, Alembic для разных СУБД) позволяет хранить SQL-скрипты изменений схемы прямо в системе контроля версий (git), формировать строгую последовательность миграций и автоматизировать обновления схемы на всех окружениях.

Пример кода (миграция через Flyway):

-- V002__add_column_email.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;

Интеграция Flyway (например, для Java):

Flyway.configure().dataSource(url, user, pass).load().migrate();

Ключевые особенности:

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

Вопросы с подвохом.

Можно ли хранить "исходное состояние" схемы (snapshot) вместо миграций? На первый взгляд «дамп» всей схемы проще миграций. Но тогда возникнут проблемы с откатом, восстановлением промежуточных состояний и слиянием изменений из разных веток. Миграции позволяют применять только новые изменения последовательно и в нужном порядке.

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

Достаточно ли только SQL-скриптов миграций или стоит хранить еще что-то? Хорошей практикой является хранение помимо sql-скриптов их описания (purpose, автор, дата), а также тестов-валидаторов на новые структурные изменения, чтобы автоматизировать контроль качества миграций.

Типовые ошибки и анти-паттерны

• Применение "ручных" изменений мимо миграций: приводит к рассинхронизации окружений.
• Редактирование существующих миграций «задним числом» — чревато порчей истории и неидемпотентными действиями.
• Игнорирование обратимых (down) миграций.

Пример из жизни

Негативный кейс

Проект использовал обычные дампы схем и "ручное" применение изменений разработчиками. После запуска обновления заказчик заметил, что часть новых колонок в боевой базе не появилась, а часть индексов удваивалась после каждой попытки обновить схему.

Плюсы:
Быстро для очень небольших проектов.

Минусы:
Сложности с поддержкой; нельзя понять, что именно было изменено и кем; невозможность отката; разные окружения расходятся.

Позитивный кейс

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

Плюсы:
Автоматизация, история, слабая вероятность багов при деплое.

Минусы:
Потребность чуть дольше документировать каждое изменение структуры.