Является ли каждая команда DDL SQL обратимой?[контроль версий базы данных]

Question

Я хочу настроить механизм отслеживания изменений схемы БД, например, описанный в разделе этот ответ:

Для каждого изменения, которое вы вносите в базу данных, вы пишете новую миграцию.Миграция обычно имеет два метода:Метод «UP», в котором применяются изменения, и метод «вниз», в котором изменения отменены.Одна команда обновляет базу данных, а также может использоваться для привлечения базы данных в конкретную версию схемы.

Мой вопрос заключается в следующем:Является ли каждая команда DDL в методе «вверх» обратимой?Другими словами, всегда ли мы можем предоставить метод «вниз»?Можете ли вы представить себе какую-нибудь команду DDL, которую нельзя «выключить»?

Пожалуйста, не принимайте во внимание типичную проблему миграции данных, когда при использовании метода «вверх» происходит потеря данных:напримеризменение типа поля с datetime (DateOfBirth) к int (YearOfBirth) мы теряем данные, которые невозможно восстановить.

Answer 1

на сервере sql каждая известная мне команда DDL представляет собой пару вверх/вниз.

Answer 2

За исключением потери данных, каждая миграция, которую я когда-либо делал, обратима.Тем не менее, Rails предлагает способ пометить миграцию как «деструктивную»:

Некоторые преобразования разрушительны в способе, который нельзя изменить.Миграции такого рода должны поднять исключение ActiveRecord :: неверносильскаямигрирование в своем методе.

См. документацию API здесь.

Answer 3

Да, вы выявили случаи потери данных либо путем их преобразования, либо просто УДАЛЕНИЯ КОЛОННЫ при миграции «вверх».

Другой пример: вы можете удалить объект SEQUENCE, потеряв тем самым его состояние.Миграция «вниз» воссоздаст последовательность, но начнется заново с 1.Это может привести к созданию повторяющихся значений в последовательности.Не проблема, если вы выполняете миграцию в пустой базе данных и хотите, чтобы последовательность в любом случае начиналась с 1, но если у вас есть некоторое количество строк данных, вам нужно, чтобы последовательность была сброшена до максимального значения. используется в настоящее время, что сложно сделать надежно, если у вас нет эксклюзивной блокировки этой таблицы.

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