Как лучше внести большие изменения в структуру бд?

Question

[LastDragon]

Есть проект на yii 1.x, встала необходимость внести довольно много изменений в бд: раньше часть свойств объектов хранилась в виде строк в этой же таблице, сейчас же они были перенесены в связанные таблицы, поэтому требуется обновить все объекты. Пока видятся два пути:



1) Стандартные миграции — можно всё туда запихать, но (а) обновлять таким образом пару тысяч объектов, ИМХО, как то неправильно (или всё-таки правильно?) и (б) в консоли будет слишком много мусора (sql запросов), который никакого интереса не представляют, но здорово мешают (правда можно переопределить $this->execute() и остальные методы и тем самым избавиться от мусора)



2) Написать консольную команды для обновления.



Что выбрать или возможно есть другие варианты?

Answer 1

[Сергей Протько]

миграции для того и нужны. И они по сути выполняются как консольные команды. По поводу мусора в консоли — а какая вам разница? Миграции должны просто накатиться корректно, у меня они вообще накатываются в ci сервере и я вообще не вижу что там происходит. Только если что-то не так пойдет на email лог скинется.

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

Answer 2

[rozhik]

Теоретически правильно 1. Практически — второй вариант.

Выбор нужно делать в зависимости от того, находится ли в продакшине сайт, или нет. Что обеспечит меньший даунтайм — то и выбирать.

Однажды пришлось менять связку 1 к 1 на 1 к многим, на таблицах с десятками миллионов записей. Реализовано было:
1. шаг — создали новые таблици
2. тригер обновления (чтобы изменял и старые и новые данные).
3. запуск консольного скрипта фонового обновления (выполнялся 7 часов, при этом не сильно грузил базу)
4. замена кода, который работал со старой структурой на новую.
5. удаление старых данных.
Суммарное время даунтайма = 0 секунд.
Итого: время обновление 10 часов. Даунтайма нет

На девелопмент машинах (с почти теми-же данными)
1. шаг — создали новые таблици
2. запуск консольного скрипта обновления (выполнялся 2 часф, при этом грузил базу, лочил таблици, и вообще ничего не работало)
3. замена кода, который работал со старой структурой на новую.
4. удаление старых данных.
Итого: время обновление 2часа часов. Даунтайма 2 часа

Comments

[Никита Гусаков]

А почему нельзя продублировать базу, выполнить миграции на дублированной и переименовать базы? Даунтайм время переименования таблиц

[Сергей Протько]

видимо в случае rozhik нельзя было допустить вообще никакого даунтайма.

[rozhik]

Потому, что привык обеспечивать SLA 99.99.