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

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

Если под удалением строк имеется в виду DELETE, удаляются строки как данные. Если используется TRUNCATE, строки также удаляются, но с другими правилами журналирования, блокировок и триггеров, зависящими от СУБД; структура таблицы при этом сохраняется.

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

SQL разделяет описание структуры данных и сами данные. DDL управляет объектами схемы, например создаёт или удаляет таблицы, а операции над строками относятся к DML.

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

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

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

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

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

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

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

Минимальное различие выглядит так:

CREATE TABLE staging (id INTEGER PRIMARY KEY);

DELETE FROM staging;
-- Таблица staging существует, но строк в ней нет.

DROP TABLE staging;
-- Объект staging больше не существует.

После DELETE таблицу можно сразу использовать для новых вставок. После DROP TABLE сначала потребуется заново выполнить CREATE TABLE, причём исходные настройки не восстановятся автоматически.

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

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

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

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

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

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

Сохраняются ли индексы после удаления всех строк?

Да, при DELETE и обычно при TRUNCATE индексы остаются частью таблицы. Меняется их содержимое, но не определение; при DROP TABLE сами индексы как объекты, принадлежащие таблице, удаляются вместе с ней.

Можно ли после очистки вставить строку с тем же первичным ключом?

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

Всегда ли удаление таблицы можно отменить транзакцией?

Нет универсального ответа. Возможность отката DDL зависит от конкретной СУБД и режима выполнения: одни системы транзакционно обрабатывают такие изменения, другие выполняют отдельные DDL-команды с особыми правилами фиксации. На практике восстановление после DROP TABLE нельзя планировать без проверки документации, резервной копии и политики восстановления.