БД и миграции При работе с базами данных нам необходимо, чтоб | Советы разработчикам (python и не только)

БД и миграции

При работе с базами данных нам необходимо, чтобы структура данных в БД соответствовала коду:
Во-первых, мы должны изначально создать необходимые таблицы или коллекции с правильными индексами и т.п.
Во-вторых, при изменении кода приложения мы должны актуализировать эту структуру, создать новые таблицы, переложить данные по другому и т.п. Даже если сама СУБД не подразумевает фиксированной схемы лежащих в ней данных, вы можете захотеть уменьшить разнообразие вариантов хранения.

Кроме этого у нас есть дополнительные ограничения:
* Код не должен иметь права отключать проверки в СУБД, менять и создавать индексы и настраивать связи;
* Запуск нескольких копий кода одновременно (актуально для веб-приложений) не должен приводить БД в неработающее состояние;
* Приложение может быть развернуто на нескольких окружениях, которые обновляются независимо;
* Иногда должна быть возможность вернуть базу данных в предыдущее состояние из-за ошибок;
* Иногда мы хотим, чтобы несколько версий кода работали одновременно. Например, при green-blue/canary deployment.

Таким образом я бы выделил следующие подходы:
1. Состав и структура таблиц должны определяться на момент проектирования/реализации версии кода. Таблицы не должны генерироваться динамически во время работы приложения;
2. Для приведения структуры БД в нужное состояние пишутся скрипты миграции;
3. Скрипты миграции вызываются администратором при деплое приложения. Приложение не должно самостоятельно вызывать скрипты миграции при старте или в другой момент во время работы;
4. Каждый скрипт миграции должен содержать все необходимые данные для его работы. Скрипт миграции не должен обращаться к основному коду приложения, так как код будет меняться, а миграция должна оставаться работоспособной;
5. Скрипт миграции не должен редактироваться после выпуска очередной версии приложения. Если вы забыли мигрировать часть данных, придется делать ещё одну миграцию;
6. Миграции необходимо проверять/тестировать. Тестовые базы данных должны обновляться только с помощью миграций;
7. Инструменты для автоматической генерации миграций могут помочь в работе, но вы должны проверять и редактировать сгенерированный код.

Если есть требование обновления без простоя, то миграции должны сохранять структуру БД совместимой для нескольких версий приложения. Иногда это потребует разбивать миграцию на несколько частей. Например, если вам необходимо переименовать колонку БД, в одной миграции вы добавите новую колонку, а старую сделаете вычислимой. Затем, только после полной выкатки новой версии кода в прод, можно будет применить вторую миграцию, удаляющую старую колонку.

Если же вы делаете эти вещи, вероятно вы используете БД неправильно:
1. Создаете таблицы во время работы программы;
2. Вызываете meta.create_all() (или аналог для вашей ORM) для создания структур БД для ваших моделей;
3. Вызываете миграции автоматически при старте приложения;
4. Импортируете в миграциях модели или другой код из основной части проекта;
5. Меняете код миграций после того как они могли быть использованы;
6. Не запускаете миграции нигде кроме прода;
7. Не читаете код автоматически сгенерированных миграций.

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

И хотя обычно эти советы дают для реляционных СУБД, так как те требуют соблюдения структуры таблиц, они также применимы и для документо-ориентированных баз данных. Вы можете обойтись без миграции для добавления nullable поля в MongoDB, но скорее всего вам потребуется её делать в том или ином виде, если вы захотите разбить колонку на две или вместо одного числа начать хранить список.

Дополнительные материалы:
* https://habr.com/ru/company/yandex/blog/511892/
* https://habr.com/ru/company/flant/blog/471620/
* https://alembic.sqlalchemy.org/en/latest/