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

Ответ 1

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

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

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

Недостатки:

• Он не имеет оптимизированного плана выполнения, кэшированного, поэтому он не будет столь же быстрым, как хранимая процедура.
• Так как это просто абстракция SELECT, она немного медленнее, чем чистая SELECT.
• Он может скрыть сложность и привести к gotchas. (Gotcha: ORDER BY не соблюдается).

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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 будет достаточно умным, чтобы оптимизировать его в любом случае), устранение этого представления иногда может облегчить вашу отладку и оптимизацию запросов (что более очевидно, что нужно сделать).

Ответ 6

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

Уважайте свои взгляды, и они будут хорошо относиться к вам.

Ответ 7

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

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

• Представления не поддерживают функцию COUNT(); однако он может поддерживать COUNT_BIG()
• Предложение ORDER BY не работает в представлении
• Регулярные запросы или хранимые процедуры дают нам гибкость, когда нам нужен другой столбец; мы можем сразу добавить столбец к регулярным запросам. Если мы хотим сделать то же самое с представлениями, тогда нам придется сначала их модифицировать.
• Индекс, созданный на вид, часто не используется
• После создания представления и если в базовой таблице добавлен или удален какой-либо столбец, он обычно не отражается в представлении до его обновления
• Операция UNION не допускается в индексированном представлении
• Мы не можем создать индекс в ситуации вложенного представления, так как мы не можем создать индекс в представлении, которое создается из другого представления.
• SELF JOIN не разрешен в индексированном представлении
• Outer Join не разрешено в индексированных представлениях
• Запросы кросс-базы данных не разрешены в индексированном представлении

Источник SQL MVP Pinal Dave

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

Ответ 8

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

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

Ответ 9

Моя самая большая "схватка" заключается в том, что ORDER BY не работает в представлении. Хотя это имеет смысл, это случай, который может вскочить и укусить, если не ожидается. Из-за этого мне пришлось отказаться от использования представлений в SPROCS (которые имеют более чем достаточно собственных проблем) в нескольких случаях, когда я не мог позже указывать ORDER BY. (Я бы хотел, чтобы была построена "FINAL VIEW" - например, возможно, включает в себя порядок по-семантике).

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

Ответ 10

Ниже приведен взломан 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