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

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

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

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

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

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

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

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

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

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

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

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

CREATE TABLE sales_snapshot AS
SELECT order_id, total
FROM orders;

CREATE VIEW current_sales AS
SELECT order_id, total
FROM orders;

После изменения orders новые строки появятся в current_sales, но не появятся в sales_snapshot без отдельного обновления. При создании таблицы на основе запроса также нельзя автоматически считать сохранёнными все ограничения, индексы и другие свойства исходной таблицы: их нужно определить отдельно, если это требуется выбранной СУБД и задачей.

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

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

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

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

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

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

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

Вопрос: Можно ли считать представление кэшем результата исходного запроса?

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

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

Ответ: Результат зависит от СУБД и конкретного изменения. Если используемый столбец удалён или его тип стал несовместимым, представление может стать невалидным, а операция изменения — быть отклонена из-за зависимости. Если столбцы добавлены, это обычно не меняет явно заданный список столбцов представления, поэтому новые столбцы не обязаны появиться в его результате.

Практический вывод — проверять зависимости перед изменением схемы и не полагаться на неявное поведение конкретной СУБД.