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

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

Понимаете ли вы, что представление это сохранённый запрос, а не таблица, и умеете ли подружить его с EF Core. В паре с C# вопрос почти всегда уходит в эту сторону: как читать view через контекст, что будет с отслеживанием изменений и почему миграции его не создают.

Как отвечать

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

В EF Core представление отображают на тип без ключа:

modelBuilder.Entity<ActiveOrder>()
    .HasNoKey()
    .ToView("active_orders");

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

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

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

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

Сортируют внутри представления и ждут этого порядка снаружи. В SQL Server сортировка в теле представления запрещена без ограничения выборки, а там, где разрешена, оптимизатор её не сохраняет: order by ставится в запросе к представлению, а не внутри него.