Я бы создал VIEW по нескольким причинам
A) Хорошо построенный вид имеет тенденцию работать быстрее, чем запрос, хотя при оптимизации запросов вы можете не заметить большой разницы.
B) Он сохраняет знание структуры базы данных в самой базе данных - добавляет хороший уровень абстракции (в качестве побочной заметки, рассмотрите использование хранимой процедуры, а не встроенный запрос - это также сохраняет знания базы данных в самой базе данных)
C) Если вам нужно внести структурные изменения в базу данных, вы можете сохранить представление согласованным, не перестраивая свой код.
ПОПРАВКА Я собираюсь изменить этот ответ в свете некоторых комментариев, чтобы уточнить некоторые моменты ...
Совершенно верно, что стандартное представление не обеспечивает реального прироста производительности по запросу. Стандартное представление материализуется во время выполнения, что существенно отличает его от удобного способа выполнения запроса той же структуры. Однако представление в индексе материализуется немедленно, и результаты сохраняются в физическом хранилище. Как и при любом дизайнерском решении, следует внимательно изучить использование индексированного представления. Нет бесплатного обеда; штраф, который вы платите за использование индексированных просмотров, возникает в виде дополнительных требований к хранению и накладных расходов, связанных с сохранением представления при наличии каких-либо изменений в базовой базе данных. Они лучше всего используются в случаях часто используемого сложного объединения и агрегирования данных из нескольких таблиц и в случаях, когда доступ к данным происходит гораздо чаще, чем он изменяется.
Я также согласен с комментариями относительно структурных изменений - добавление новых столбцов не повлияет на представление. Если, однако, данные перемещаются, нормализуются, архивируются и т. Д., Это может быть хорошим способом изолировать такие изменения от приложения. Эти ситуации являются РЕДКО, и одни и те же результаты могут быть достигнуты за счет использования хранимых процедур, а не вида.