В схеме хранятся таблица и зависящее от неё представление. Какой главный риск создаёт замена RESTRICT на CA...

CREATE SCHEMA reporting;

CREATE TABLE reporting.daily_orders (
    order_id INTEGER PRIMARY KEY,
    total DECIMAL(12, 2) NOT NULL
);

CREATE VIEW reporting.recent_orders AS
SELECT order_id, total
FROM reporting.daily_orders;

DROP SCHEMA reporting CASCADE;

Краткий ответ

DROP SCHEMA reporting CASCADE удалит схему вместе с объектами внутри неё, включая таблицу и представление. Главный риск — каскадное удаление зависимых объектов без отдельного подтверждения каждого из них; в некоторых СУБД могут затронуться и внешние объекты, зависящие от удаляемых объектов.

RESTRICT предназначен для безопасной проверки: команда завершается ошибкой, если схема не пуста или существуют препятствующие зависимости. CASCADE удобен для контролируемого удаления временной или полностью выводимой из эксплуатации подсистемы, но опасен в общей рабочей схеме.

Исторический контекст

Схема появилась как логическое пространство имён для группировки таблиц, представлений, типов и других объектов. Это позволяет разделять подсистемы, управлять правами и обращаться к объектам квалифицированными именами вроде reporting.daily_orders.

При удалении объекта возникает проблема зависимостей: представление использует таблицу, функция может использовать представление, а внешние объекты могут ссылаться на них. Режимы RESTRICT и CASCADE дают два разных подхода: остановить опасную операцию или автоматически обработать граф зависимостей.

Постановка проблемы

В примере recent_orders зависит от daily_orders, а оба объекта принадлежат схеме reporting. Удаление только контейнера невозможно без решения судьбы его содержимого.

Если без проверки применить CASCADE, исчезнет не только схема, но и её объекты. Если от них зависели отчёты, права, процедуры или объекты в других схемах, приложение может потерять доступ к данным или перестать компилировать запросы.

Подробное решение

DROP SCHEMA reporting CASCADE обрабатывает операцию как удаление схемы с каскадным уничтожением её содержимого. В данном примере будут удалены reporting.daily_orders, reporting.recent_orders и сама схема reporting.

DROP SCHEMA reporting RESTRICT;
-- Ошибка, если схема содержит объекты или есть препятствующие зависимости

DROP SCHEMA reporting CASCADE;
-- Схема и разрешённые правилами СУБД зависимые объекты удаляются

RESTRICT не означает «удалить только схему без объектов». Он означает «не выполнять удаление, если содержимое или зависимости требуют каскадного действия». Это защитный режим, позволяющий сначала изучить состав схемы и подготовить явный план миграции.

CASCADE не является универсальной заменой резервному копированию или анализу зависимостей. Точный набор удаляемых внешних объектов, возможность отката DDL, требования к правам и поведение транзакций зависят от конкретной СУБД. Поэтому перед операцией нужно проверить системный каталог зависимостей, права и наличие резервной копии.

Практический компромисс таков: для временных схем тестов допустим CASCADE; для рабочей схемы обычно выбирают RESTRICT, явно удаляют или заменяют объекты в нужном порядке и отдельно проверяют потребителей.

Ситуация из практики

Команда выводит из эксплуатации модуль отчётности. В его схеме находятся десятки представлений, таблиц и процедур, но часть представлений используется внешним BI-сервисом.

Рассматривались три варианта:

1. Сразу применить DROP SCHEMA ... CASCADE — быстро, но есть риск незаметно удалить объекты, нужные BI-сервису.
2. Применить RESTRICT и остановиться на ошибке — безопасно, но само по себе не показывает готовый план удаления.
3. Проанализировать зависимости, отключить потребителей, удалить объекты явно и затем схему — требует больше времени, зато изменения контролируемы и проверяемы.

Выбран третий вариант. Сначала владельцы BI подтвердили список объектов, затем команда удалила устаревшие зависимости отдельными миграциями и только после проверки выполнила удаление схемы. Это снизило риск скрытого удаления и упростило аудит изменения.

Что кандидаты часто упускают

1. Удаляет ли CASCADE только объекты внутри указанной схемы?

Нет, не обязательно. Объекты внутри схемы удаляются как содержимое схемы, но от них могут зависеть объекты за её пределами. Конкретная СУБД может удалить такие внешние зависимости каскадно, изменить их состояние или запретить операцию.

Поэтому нельзя оценивать риск только по списку объектов, возвращаемому для самой схемы. Нужно изучать направленные зависимости: кто использует удаляемые таблицы, представления, типы и функции.

2. Гарантирует ли RESTRICT, что база останется полностью без изменений?

Нельзя автоматически переносить такое предположение на любую СУБД. Обычно при обнаружении препятствующей зависимости команда завершается ошибкой, но детали атомарности DDL и транзакционного поведения различаются.

Надёжная миграция должна учитывать документацию конкретной СУБД: выполняется ли DDL в транзакции, какие проверки происходят до изменения каталога и может ли частично выполненная составная миграция оставить промежуточное состояние.

3. Можно ли восстановить схему после успешного CASCADE?

Сам по себе CASCADE не создаёт автоматический механизм восстановления. Восстановление зависит от резервной копии, журнала транзакций, поддержки отката DDL и возможности воссоздать не только таблицы, но и данные, права, представления, процедуры и зависимости.

Поэтому перед разрушительной операцией нужны проверенная резервная копия или иной способ восстановления, зафиксированная DDL-структура и план обратного переключения. Наличие команды CREATE SCHEMA после удаления недостаточно: она восстановит только контейнер, но не его содержимое и состояние.