При удалении столбца из таблицы что происходит с ограничениями, которые зависят от этого столбца?
Зависимое ограничение нельзя оставить в прежнем виде: при режиме RESTRICT удаление столбца завершается ошибкой, а при CASCADE ограничение удаляется вместе со столбцом. Точное поведение и поддержка этих режимов зависят от конкретной СУБД, но общий принцип таков: DDL учитывает зависимости между объектами схемы.
Схема реляционной базы данных состоит не только из таблиц и столбцов, но и из ограничений, индексов, представлений и других связанных объектов. Такой подход нужен, чтобы СУБД могла сохранять целостность схемы при её изменении, а не допускать ссылки на уже несуществующие элементы.
Поэтому удаление части таблицы — это не просто изменение физического хранения. СУБД должна определить, какие объекты схемы больше нельзя корректно интерпретировать после этой операции.
Предположим, столбец участвует в ограничении UNIQUE, CHECK, внешнем ключе или другом объекте, который ссылается на его имя. После удаления столбца выражение ограничения может потерять смысл, а проверка целостности — стать невозможной.
Без защитного режима случайное удаление столбца могло бы незаметно изменить правила приема данных. Поэтому безопасная стратегия обычно требует явно выбрать: остановить операцию и обработать зависимости вручную либо удалить зависимые объекты автоматически.
При RESTRICT СУБД проверяет зависимости и отклоняет операцию, если от удаляемого столбца зависит ограничение. Это наиболее безопасный режим для продуктивной схемы: разработчик видит полный список затронутых объектов и может принять решение отдельно для каждого из них.
При CASCADE удаление распространяется на зависимые объекты. Например, если столбец имеет ограничение UNIQUE, это ограничение также исчезает; если объект зависит от нескольких столбцов и хотя бы один удаляется, результат зависит от типа зависимости и реализации СУБД.
Минимальный пример для СУБД, поддерживающей такие режимы:
После операции исчезает не только sku, но и ограничение UNIQUE, построенное на нём. При выборе RESTRICT та же операция должна быть отклонена из-за зависимости.
Важно отличать ограничения от независимых объектов. Например, ограничение, использующее удаляемый столбец, не может продолжать работать; но объект, который не ссылается на этот столбец, сам по себе удаляться не должен. Реальное множество каскадно удаляемых объектов, синтаксис и названия режимов нужно проверять по документации конкретной СУБД.
В таблице заказов столбец customer_id участвует во внешнем ключе и используется представлением отчетности. Команда хочет удалить его как устаревший атрибут.
Вариант с CASCADE прост и быстро удаляет зависимые ограничения и объекты, но создаёт риск потери представления или правил целостности, о которых команда не вспомнила. Вариант с RESTRICT останавливает миграцию, зато заставляет явно найти зависимости и оценить последствия.
Практичное решение — сначала выполнить проверку зависимостей в тестовой среде, отдельно удалить или изменить представление и ограничения, затем удалить столбец в контролируемой миграции. Такой подход дольше, но сохраняет предсказуемость схемы и позволяет не потерять правила данных из-за широкого каскада.
Если внешний ключ использует удаляемый столбец, он становится зависимым объектом. При RESTRICT операция обычно отклоняется, а при CASCADE внешний ключ удаляется вместе со столбцом; автоматически перенести его на другой столбец СУБД не может.
Нет. Успешное выполнение означает, что СУБД смогла удалить запрошенный объект и разрешённые зависимости, но не означает сохранение бизнес-правил. Каскад может удалить ограничения, индексы, представления или другие зависимые объекты, поэтому результат миграции нужно проверять по схеме и тестам целостности.
Ограничение, зависящее от удаляемого столбца, больше нельзя сохранить в исходном виде. В режиме RESTRICT операция должна быть отклонена, а в режиме CASCADE составное ограничение удаляется целиком, а не превращается автоматически в ограничение на оставшиеся столбцы. Если новое правило нужно сохранить, его следует определить явно после изменения схемы.