В чем суть миграций БД?

Question

[Леша]

Здравствуйте.
В данный момент изучаю Flask, проходя данный туториал:
https://blog.miguelgrinberg.com/post/the-flask-meg...
Так как никакого опыта работы с БД я не имею (совсем чайник), то возникло несколько вопросов после прочтения:
https://blog.miguelgrinberg.com/post/the-flask-meg...

Автор данного туториала использует ORM SQLAlchemy.
После прочтения осталось неясным:
1. Что такое миграция, для чего конкретно нужна и как это связанно с сохранением данных?
2. Чем миграция отличается от db_upgrade or db_downgrade?
3. Что будет, если миграции не производить?

По данным ссылкам ничего не нашел (так и не понял, зачем они мне нужны):
1. ru.stackoverflow.com/questions/325882/Зачем-нужны-миграции - Stack Overflow
2. Зачем нужны миграции? - Toster

Answer 1

[sim3x]

1. Что такое миграция, для чего конкретно нужна и как это связанно с сохранением данных?

переход от одной структуры БД к другой без потери косистентности

2. Чем миграция отличается от db_upgrade or db_downgrade?

миграция подразумевает как прямое изменение апгрейд, так и обратное изменение - даунгрейд

3. Что будет, если миграции не производить?

миграции можно не делать,
если данные не важны и их можно просто удалить из БД,
если приложение не развивается и/или не меняет структуру хранения

Comments

[Леша]

В данном туториале приводятся три скрипта: db_migrate.py, db_upgrade.py и db_downgrade.py, если разница между upgrade и downgrade предельно ясна, то присутствие db_migrate - нет.
Прошу прощения, если это очень очевидно, но для меня это пока что неясно.

[sim3x]

Леша: в db_migrate определяется что вызывать upgrade или downgrade

[Леша]

sim3x: на основе чего db_migrate определяет, что вызвать?

[sim3x]

Леша: чаще всего - прямое указание программера
Реже - логика, прописанная внутри скрипта

[Леша]

sim3x: с этим я, кажется, разобрался. Не могли бы вы привести простейший пример потери консистентности данных в этом контексте?

[sim3x]

Леша: изменилась модель хранения
Добавили пару полей, БД потеряла 3нф
Для восстановления 3нф нужно создать еще одну модель

Теперь нужно переместить часть данных в новую модель
Если не делать миграцию, то связм потеряются = нет консистентности

А без миграции, есть только вариант с удалением таблицы и созданием двух новых

[Леша]

sim3x: Понятно. И напоследок - миграцию нужно проводить после каждого небольшого изменения, или только после масштабных?

[sim3x]

Леша: миграции производятся при изменении полей моделей

Те, поменялся тип поля у модели = миграция
добавилось поле = миграция

Обьем изменений неважен

Причем не всегда изменения возможно провести в один заход. Иногда приходится делать две и более миграции для изменения одного поля

[Леша]

sim3x: Спасибо.

[89109983838]

поменялся тип поля у модели = миграция
добавилось поле = миграция

а если поступить так:
остановить сервер
в базе данных (Mysql) ручками произвести изменения
далее в моделях flask подправить соотвествено
далее стратануть веб сервер...

ТАК НЕЛЬЗЯ? ПОЧЕМУ?
На PHP сайтах делаемже и ничо вроде живы!

[sim3x]

89109983838: в питоне говокодить не принято

[89109983838]

sim3x,
Тоесть разработчики PHP (да и других языков) сайтов в течении лет так 30 как минимум говнокодили???
Чот как то не укладывается в голове это определение необходиости миграции!!?

Да и понятие "говнокод ...." это должен быть код, а не его отсутствие (если не используется миграция то и кода миграции нет)
Наверно говнокод будет - когда я к примеру не умелыми ручками буду эту миграцию править, когда что то не так в друг пойдет вней, читать лишние мануалы, искать примеры в сети, на том же Toster.ru задавать лишние вопросы по миграции (сам же на них потом отвечать.....%) - Хотяб мог поправить базу да и все, и переписать функции приложения где надо (их в любом случае править - есть миграция или нет..).

//#P.S.: **!>#//

Хотя в свете текущего интереса к MangoBD - вспомнил вдруг про этот мой Давнишний коментарий в вопросе "В чем суть миграций БД" который менято же очень интересовал в Flask-SQLAlchemy.
Документацию по самой миграции изучил вдоль и поперек еще до этого вопроса. Но зачем это в обязательном порядке так и не понял!
Сегодня в свежем ключе - ответ на вопрос вижу так:
Это по сути управление структурой базы данных из самого приложения - вне зависимости самой базы Mysql, MangoBD или даже Постгресом главное соблюсти её "синтексис" в запросах, а сама модель данных контролируется приложением (причем достаточно жестко).
Далее из этого мог бы "рисовать" своим не опытным сознанием некоторые выводы! - Но выскажусь попроще - "Блин попахивает идеей NoSQL, в не зависимости от вида DB " и не просто попахивает а таращит..... если конечно мы на одной волне.

[sim3x]

89109983838, да, все время говнокодили
Только не 30, а 22

Отсутствие необходимого кода - также говнокод

Миграции требуются в проектах, которые развиваются и поддерживаются

NOSQL хайп уже давно прошел, им все переболели и забыли

[0x131315]

89109983838,

Чот как то не укладывается в голове это определение необходиости миграции!!?

Миграции - это история изменений структуры БД во времени
Они хранятся вместе с приложением

Новый код рассчитан на работу с последней версией БД
При обновлении приложения код определяет версию текущей БД (номер последней примененной к ней миграции), и по очереди применяет к БД новые миграции, повышая версию БД до необходимой коду для нормальной работы
Таким образом нет необходимости вручную следить за структурой БД, и менять ее

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

Answer 2

[awesomer]

СУБД можно разделить на 2 группы:

1. С заранее определенной схемой данных (определенным списком таблиц и их колонок)
   
2. И бессхемные
   

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

Answer 3

[FRANZEE]

Хорошая статья на эту тему - https://habr.com/ru/post/121265/

Answer 4

[Антон Коновалов]

Рекомендую ознакомиться с хорошим мануалом по миграциям в Django - возможно это вас приблизит к пониманию сути процесса.