Что такое view в SQL?

Что проверяют

Различаете ли вы логическую схему и физическое хранение и понимаете ли, во что представление превращается при выполнении. Для Java-разработчика вопрос почти всегда продолжается в сторону ORM: как такой объект ложится на сущность и что с ним делает Hibernate.

Как отвечать

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

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

create view active_orders as
select o.id, o.created_at, c.title
from orders o join customers c on c.id = o.customer_id
where o.status = 'active';

Простые представления обновляемы, для сложных пишут триггер вместо записи; with check option не даёт вставить через представление строку, которая в него потом не попадёт.

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

Где спотыкаются

Считают представление кэшем. Оно раскрывается в исходный запрос, и медленное соединение останется медленным; путают его с материализованным, забывая, что у того данные устаревают до следующего обновления.

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

Мапят view как обычную сущность и получают попытку записи при сбросе контекста. Сюда же миграции: замена тела представления на месте не меняет состав и порядок колонок, и деплой падает на первой же новой колонке.