Каковы недостатки использования SqlServer Views?

Question

Каковы недостатки использования SqlServer Views?

Я часто создаю представления для отображения моих данных в денормализованной форме.

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

Но стоит ли создавать и использовать эти представления?

Я замедляю (или ускоряю?) Обработку запросов?

Answer 1

Когда речь заходит о представлениях, есть свои преимущества и недостатки.

Преимущества:

1. Они являются виртуальными таблицами и не хранятся в базе данных как отдельный объект.Все, что сохраняется, - это оператор SELECT.
2. Он может использоваться в качестве меры безопасности, ограничивая то, что может видеть пользователь.
3. Он может облегчить чтение часто используемых сложных запросов, инкапсулируя ихв вид.Однако это обоюдоострый меч - см. Недостатки № 3.

Недостатки:

1. У него нет кэшированного оптимизированного плана выполнения, поэтому он будет работать не так быстро, какхранимая процедура.
2. Так как это просто абстракция SELECT, он немного медленнее, чем чистый SELECT.
3. Это может скрыть сложность и привести к ошибкам.(Поправлено: ORDER BY не соблюдается).

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

Answer 2

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

Для особенно большого и сложного проекта я разработал набор представленийкоторые должны были использоваться в основном дизайнерами отчетов для заполнения отчетов.Несколько недель спустя я обнаружил, что младшие разработчики начали использовать эти представления для извлечения агрегатов и присоединения к этим уже большим представлениям просто потому, что они были там и их было легко использовать.(В базе данных был сильный элемент дизайна EAV.) Я узнал об этом после того, как младшие разработчики начали спрашивать, почему, казалось бы, простые отчеты занимают много минут.

Answer 3

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

В SQL Server вы также можете создавать материализованные или индексированные представления (начиная с SQL Server 2000), что несколько увеличивает скорость.

Answer 4

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

SELECT ... 
FROM (View with complex UNION of ActiveCustomer and InactiveCustomer tables)
WHERE Active = True 

(таким образом, отфильтровывая все строки, которые были включены в представление из таблицы InactiveCustomer), или

SELECT (one column)
FROM (view that returns 50 columns)

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

SELECT ...
FROM (view with complex filters)
WHERE (entirely different filters)

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

SELECT (only fields from a single table)
FROM (view that contains crazy complex joins)

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

SELECT ...
FROM (Crazy UNION of 12 tables each containing a month of data)
WHERE OrderDate = @OrderDate

(Читает 12 таблиц, когда действительно нужно прочитать только 1).

В большинстве случаев SQL достаточно умен, чтобы «проследить сквозь крышки» и в любом случае придумать эффективный план запросов. Но в других случаях (особенно очень сложных) это невозможно. В каждой из вышеперечисленных ситуаций ответ состоял в том, чтобы удалить представление и запросить базовые таблицы.

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

Answer 5

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

РЕДАКТИРОВАТЬ: сказав это, я нахожу удобство и преимуществовозможность упрощения и повторного использования сложных запросов перевешивает проблему обслуживания, особенно если представления используются ответственно.

Answer 6

Что такое различные ограничения представлений в SQL Server?

Топ 11 ограничений просмотров

• Представления не поддерживают COUNT (); однако он может поддерживать COUNT_BIG ()
• Предложение ORDER BY не работает в View
• Регулярные запросы или хранимые процедуры дают нам гибкость, когда нам нужен другой столбец; мы можем сразу добавить столбец в регулярные запросы. Если мы хотим сделать то же самое с представлениями, то нам придется сначала изменить их
• Индекс, создаваемый в представлении, используется не часто
• После создания представления и добавления или удаления столбца в базовой таблице оно обычно не отражается в представлении до его обновления
• UNION Работа в индексированном представлении запрещена
• Мы не можем создать индекс для вложенной ситуации просмотра, то есть мы не можем создать индекс для представления, построенного из другого представления.
• САМОСОЕДИНЕНИЕ не разрешено в индексированном представлении
• Внешнее соединение не разрешено в индексированных представлениях
• Кросс-запросы к базам данных не разрешены в индексированном представлении

Источник SQL MVP Пиналь Дэйв

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/

Answer 7

Недостатком представлений, с которыми я столкнулся, является падение производительности при включении их в распределенные запросы.В этой статье SQLMag обсуждается - и хотя в демонстрации я использую искусственные данные, я снова и снова сталкиваюсь с этой проблемой в «реальном мире».и они будут хорошо к тебе относиться.

Answer 8

Когда я начинал, я всегда думал, что представления увеличивают производительность, но опыт рисует другую историю (сам механизм представления имеет незначительные издержки).

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

Answer 9

Ниже приведен взлом SQL, позволяющий ссылаться на порядок в представлении:

create view toto1 as 
select top 99.9999 percent F1
from Db1.dbo.T1 as a 
order by 1

Но я предпочитаю использовать Row_Number:

create view toto2 as 
select *,  ROW_NUMBER() over (order by [F1]) as RowN from ( 
select f1
from Db1.dbo.T1) as a

Answer 10

Моя самая большая проблема: ORDER BY не работает в представлении. Хотя это имеет смысл, это случай, который может вскочить и укусить, если не ожидается. Из-за этого мне пришлось переключить без с использования представлений на SPROCS (у которых более чем достаточно собственных проблем) в некоторых случаях, когда я не мог указать ORDER BY позже. (Хотелось бы, чтобы была конструкция с «ФИНАЛЬНЫМ ВИДОМ» - например, возможно, включить порядок по семантике).

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/ (ограничение № 1 касается ЗАКАЗА ПО: -)