Этот вопрос касается представлений базы данных, не материализованных представлений.
Плюсы:
Минусы:
Что еще?
Плюсы: Позволяет изменять базовые структуры данных, не влияя на запросы, которые используются приложениями (пока ваше представление может скрывать структуры данных).
Безопасность. Предоставьте доступ к представлению пользователям, которые должны иметь возможность видеть столбцы, возвращенные из него.
Представления довольно удивительны, если вы не полностью доверяете стороне, отправляющей запросы в вашу базу данных. Хорошим примером может быть то, что вы создадите представление для таблиц для подрядчика, чтобы все, что они могли видеть, это строки, относящиеся к их проекту.
Теперь, когда SQL Server имеет общие выражения таблиц, я нахожу, что создаю меньше просмотров. Когда я создаю представление, это обычно для нормализованной иерархии, которая может использоваться во многих запросах, а не в том, что заменяет один запрос.
Например, для региона, рынка и города могут быть три нормализованных стола (снежинка). 90% моих запросов нуждаются в этих данных, поэтому я создам представление. Представление никогда не заменяет один запрос, но делает все остальные запросы простыми и сухими.
Хотя представления могут скрывать сложность и множественные объединения, это сложность, которая была бы в SP в любом случае.
Если бы SP мог быть оптимизирован, тогда представление должно быть оптимизировано, что приведет к повышению производительности всех SP, которые попали в это представление.
Представления невероятно мощны и полезны по одной причине, которая выделяется выше всех других очень веских причин. Они уменьшают дублирование кода. То есть, в большинстве случаев, в нижней строке. Если запрос будет использоваться в трех или более местах, тогда представление значительно упростит ваши изменения, если параметры схемы или запроса изменится.
Мне пришлось отредактировать 22 хранимых процедуры, чтобы изменить некоторую логику запросов. Если исходная архитектура использовала представления, тогда у меня было бы только три изменения.
Мне приходилось несколько раз использовать представления для создания странных объединений и группировки с помощью псевдонимов.
По странным объединениям я имею в виду выбор списка отдельных дат, а затем внешнее присоединение к ним обратно в таблицу, из которой они пришли, для получения пустых записей в течение пустых дней. Я не мог понять, как это сделать.
Что касается группировки с помощью псевдонимов, то это, казалось, зависело от сложности формулы внутри псевдонима. Если псевдоним не ссылался на какие-либо фактические столбцы или столбцы, которые уже были сгруппированы, все было в порядке, но псевдонимы столбцов, которые не были включены в группировку, вызывали ошибки.
Кажется, я вспоминаю чтение или слух где-то в течение моих университетских дней, что выбор из представления был быстрее, чем выбор из группы объединенных таблиц, но я не знаю, правда ли это.
Последнее преимущество использования представления: сводные таблицы в Excel. Я не думаю, что есть способ объединения таблиц или, по крайней мере, не в интерфейсе мастера. Возможно, возможно сделать соединения в Microsoft Query, но я еще не пробовал, потому что теперь мне пришла в голову мысль.
Я использовал их все время, теперь редко. Тем не менее, я делаю весь доступ к данным через хранимые процедуры, поэтому полезность представления несколько меньше, поскольку SP может скрыть сложность соединения там, где это необходимо.
Я бы все же подумал о том, чтобы использовать представление, если у него было особенно сложное соединение со многими таблицами, из которого мне нужно было построить много SP поверх, но, честно говоря, я не могу думать ни о чем, производство прямо сейчас.
Другой сценарий, который я использовал бы, - это то, где мои пользователи имеют доступ к базе данных для генерации собственных отчетов, и я хотел скрыть их сложность.