Когда использовать представления базы данных, а когда нет?

Question

Этот вопрос касается представлений базы данных, не материализованных представлений.

Плюсы:

• Упрощение запросов.
• Избегайте повторения одинаковых объединений в запросах с несколькими множителями.
• Избегайте магических чисел.

Минусы:

• Скрытие реальных запросов (может быть, вы повторяете объединения).

Что еще?

Answer 1

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

Answer 2

Плюсы: Позволяет изменять базовые структуры данных, не влияя на запросы приложений (если ваше представление может скрывать структуры данных)

Answer 3

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

Answer 4

Хотя представления могут скрывать сложность и множественные объединения, это сложность, которая в любом случае была бы в SP.

Если бы SP мог быть оптимизирован, то представление должно быть оптимизировано, что приведет к повышению производительности на всех SP, которые обращаются к этому представлению.

Представления невероятно мощные и полезные по одной причине, которая выделяется над всеми остальными очень вескими причинами. Они уменьшают дублирование кода. То есть, в большинстве случаев, суть. Если запрос будет использоваться в трех или более местах, то представление существенно упростит ваши изменения, если схема или параметры запроса изменятся.

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

Answer 5

Теперь, когда в SQL Server общие табличные выражения , я создаю меньше представлений. Когда я создаю представление, обычно это нормализованная иерархия, которая может использоваться во многих запросах, а не что-то, что заменяет один запрос.

Например, Регион, Рынок и Город могут быть тремя нормализованными таблицами (снежинка). 90% моих запросов нуждаются в этих данных, поэтому я создам представление. Представление никогда не заменяет один запрос, но делает все остальные запросы простыми и СУХИМЫМИ.

Answer 6

Мне приходилось несколько раз использовать представления для выполнения странных объединений и группировки по псевдонимам.

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

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

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

Последнее преимущество использования представления: сводные таблицы в Excel. Я не думаю, что есть способ объединения таблиц или, по крайней мере, не в интерфейсе мастера. Возможно, можно выполнять объединения в Microsoft Query, но я еще не пробовал, потому что эта мысль пришла мне в голову сейчас.

Answer 7

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

Я бы по-прежнему подумал об использовании представления, если бы у a было особенно сложное объединение многих таблиц, из которого мне нужно было потом построить множество SP, но, честно говоря, я не могу думать о том, что есть производство прямо сейчас.

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