Какой смысл миграции баз данных «вниз»?

Question

Как и должно быть во всех базах данных, источник для нашей версии имеет контроль версий. База данных обновляется с использованием серии сценариев SQL, сгенерированных инструментом сравнения Red Gate, который по сути аналогичен миграции «вверх» в многочисленных средах миграции базы данных, которые, похоже, появились недавно.

Но какой смысл в миграциях «вниз» в этих рамках? Часто код для миграции «вверх» является чрезвычайно сложным (как правило, сложная миграция данных по мере развития функций), и я пытаюсь понять, как нужно написать все в обратном порядке для «вниз». Это то, чего я никогда не чувствовал. Я что-то здесь упускаю ...?

Answer 1

Похоже, что уместный вопрос здесь:

• Почему откат по сценарию предпочтительнее полного восстановления базы данных из резервной копии, сделанной непосредственно перед обновлением?

Я могу придумать несколько причин:

1. База данных очень велика, скажем, несколько сотен ГБ, и ваша компания не может позволить себе простои и / или административные издержки, которые могут потребоваться для полного восстановления.

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

3. Ошибка не была обнаружена до месяцев в выпуске. Другими словами, у вас даже нет резервной копии , и вы официально находитесь в режиме контроля повреждений / аварийного восстановления. Я никогда не испытывал этого, но я слышал истории. Это страшная мысль - как вы можете отменить весь ущерб, который был нанесен? В этом случае ваш рейтинг может быть не идеальным, но он все же может быть лучше, чем альтернатива.

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

5. Вы развертываете на сайтах клиентов. Некоторые из них могут вообще не иметь резервных копий (да, это жалко, но вы ничего не можете с этим поделать). Если одному из них требуется откат, это единственный вариант.

Могут быть и другие причины иметь сценарии перехода на более раннюю версию - это просто не в моей голове.

Answer 2

Заказчик: «Нам не нравится новая версия, и мы хотим вернуться к старой версии».

Answer 3

1. Rollbacks. Вы толкаете все в производство, и оно взрывается - миграция вниз является хорошей защитной сеткой для отката.
2. Или вы разрабатываете с несколькими ветвями кода - вы можете переходить между версиями к своему сердцу.

Answer 4

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

Но вы можете обойти вышесказанное, восстановив резервную копию и используя SQL Data Compare для копирования дополнительных данных.