Миграция описывает последовательность изменений, которые необходимо применить к базе данных. Эти изменения могут включать создание новых таблиц, изменение существующих, добавление или удаление столбцов, создание индексов, изменение ограничений и так далее
Миграция должна удовлетворять свойству идемпотентности - свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом. Для осуществления этого в PostgreSQL есть фраза IF NOT EXISTS
Скрипты с миграциями лучше всего версионировать, например, называть:
00001.sql, 00002.sql0.0.1.sql, 0.1.0.sql (семантическое версионирование)20250326_193204.sql, 20250330_074332.sqlПомимо скрипта применения миграции рекомендуется иметь скрипт для отката. Тогда прямые изменения называют up-миграцией, а обратные - down-миграцией
Миграции можно генерировать при помощи:
описания на xml и подобных языках (например, как в утилитах для деплоя баз данных Liquibase и Flyway)
ООП-кода и фреймворков, делающих ORM-преобразования; это позволяет синхронизировать доменные модели со схемой базы данных, однако теряется контроль над сырыми SQL-запросами (например, Django в Python или Hibernate, Spring в Java)
Также хорошей практикой будет иметь служебную табличку в базе данных, которая хранит список примененных миграций
Во время совершения миграций могут возникнуть сложности, такие как нарушение обратной совместимости или повышенная нагрузка на БД
Например, операция
ALTER TABLE table_name ADD COLUMN SET DEFAULT;
является небезопасной, приводящая к даунтауму, так как она блокирует всю таблицу, пока ставит дефолтные значения каждой записи. Правильным решением будет:
ALTER TABLE table_name ADD COLUMN column_name data_type;
ALTER TABLE table_name ALTER COLUMN column_name SET DEFAULT default_value;
Чтобы изменить схему таблицы и переместить даные в ходе миграции, можно поступить так:
Такие ETL-инструменты (от Extract-Transform-Load) как Apache NiFi, Pentaho Data Integration, Apache Airflow могут автоматически производить миграции данных