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

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

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

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

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

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

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

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

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

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

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

Режим RESTRICT требует отсутствия зависимостей. В некоторых СУБД отсутствие явного режима ведёт к ограничительному поведению, но полагаться на это без изучения документации нельзя. DROP также удаляет данные таблицы вместе с её структурой, тогда как DELETE удаляет строки, сохраняя таблицу и её зависимости.

Минимальный пример для PostgreSQL:

CREATE TABLE client (
    id integer PRIMARY KEY
);

CREATE TABLE orders (
    id integer PRIMARY KEY,
    client_id integer REFERENCES client(id)
);

DROP TABLE client; -- ошибка из-за зависимости
DROP TABLE client CASCADE; -- удаление зависимостей

Первый оператор не выполняется, потому что ограничение в таблице orders ссылается на client. Второй оператор удаляет таблицу client и зависимое внешнее ограничение; точный перечень каскадируемых объектов нужно проверять по документации используемой СУБД.

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

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

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

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

Удалит ли удаление родительской таблицы строки в дочерней таблице?

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

Каскадное удаление строк задаётся свойством внешнего ключа для операций над данными и действует при удалении строк родительской таблицы. Это отдельная настройка от режима CASCADE у DROP.

Можно ли безопасно заменить DROP CASCADE удалением внешнего ключа перед удалением таблицы?

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

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

Почему переименование таблицы часто безопаснее её удаления и повторного создания?

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

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