Создать индекс по представлению SQL с операторами UNION? Это действительно улучшит производительность?

Question

Я пытаюсь создать индекс в следующем представлении:

SELECT     'Candidate' AS Source, CandidateID AS SourceId, LastName + ', ' + FirstName AS SourceName
FROM         dbo.Candidates
UNION
SELECT     'Resource' AS Source, ResourceID AS SourceId, LastName + ', ' + FirstName AS SourceName
FROM         dbo.Resources
UNION
SELECT     'Deal' AS Source, DealID AS SourceId, CONVERT(varchar, Number) + '-' + CONVERT(varchar, RevisionNumber) AS SourceName
FROM         dbo.Deals
UNION
SELECT     'Job Order' AS Source, JobOrderID AS SourceId, CustomerNumber AS SourceName
FROM         dbo.JobOrders

Я получаю следующую ошибку:

Msg 1939, Level 16, State 1, Line 2
Cannot create index on view '_Source' because the view is not schema bound.

Я добавил WITH SCHEMABINDING в CREATE и теперь получаю следующую ошибку:

Msg 10116, Level 16, State 1, Line 2
Cannot create index on view 'DEALMAKER.dbo._Source' because it contains one or more UNION, INTERSECT, or EXCEPT operators. Consider creating a separate indexed view for each query that is an input to the UNION, INTERSECT, or EXCEPT operators of the original view.

Мои вопросы:

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

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

Заранее спасибо!

Answer 1

Вы не можете создать индекс для представления, которое использует оператор объединения. На самом деле нет пути, прости!

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

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

Answer 2

Почему в МИРЕ вы используете UNION?

С литералами в вашем SQL -коде есть нулевой шанс, что у вас будут дубликаты. Итак, еще раз, зачем использовать UNION?

UNION заставляет возникать отдельное событие, и оно немного медленнее, чем DISTINCT.

Но так как у вас есть что-то похожее на это:

SELECT 'A'
UNION
SELECT 'B'
UNION
SELECT 'C'

Нет никакой вероятности, что у вас когда-нибудь будут дубликаты.

Измените его на UNION ALL, и ваш запрос будет выполняться намного быстрее.

Это фундаментальный SQL - написание хорошо настроенного запроса важнее, чем создание индексов представления. Начните с основ, разберитесь с SQL, настройте запрос, ЗАТЕМ беспокойтесь о расходе места и замедлении DML для повышения скорости запросов.

РЕДАКТИРОВАТЬ:

Литералы в запросе предотвращают дублирование между таблицами. Единственная оставшаяся возможность - дупс в таблице (ах). Поскольку столбцы выглядят как PK, и нет никаких объединений, которые могли бы вызвать дублирование, и поскольку все таблицы выглядят как справочные таблицы, то, что я сказал, правильно. Если это предположение неверно, вы можете законно использовать UNION без ALL. Однако я считаю, что в 99% случаев люди действительно хотели использовать ALL, и в нашей компании принято добавлять комментарии к SQL только с UNION, потому что это часто ошибка. т.е. UNION - да, мне нужен отдельный список.