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

Question

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

Я часто создаю виды, чтобы показывать свои данные в денормализованной форме.

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

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

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

Answer 1

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

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

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

Недостатки:

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

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

Answer 2

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

В SQL Server вы также можете использовать create materialized or indexed views (с SQL Server 2000), которые несколько увеличивают скорость.

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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) 

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

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

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

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

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

Answer 8

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

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

Answer 9

Каковы различные ограничения на соображениях в SQL Server?

Лучшие 11 Ограничения Просмотров

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

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

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

Answer 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