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

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

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 CCHEMABINDING в 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.

Мои вопросы:

Как создать индекс в этом представлении? Создает ли отдельные индексированные представления действительно?

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

Спасибо заранее!

Ответы

Ответ 1

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

Я бы предположил, что вы это видели, но посмотрите эту страницу MSDN. Он дает требования к индексированным представлениям и объясняет, что они собой представляют и как они работают.

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

Ответ 2

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

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

UNION заставляет различать свое происхождение и немного медленнее DISTINCT.

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

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

Невозможно, чтобы у вас были дубликаты.

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

Это основополагающий SQL-запрос, который хорошо настроил запрос, является более важным, чем создание индексов представления. Начните с основ, понимайте SQL, настройте свой запрос, ТОГДА беспокоитесь о том, чтобы тратить пространство и замедлять DML, чтобы улучшить скорость запроса.

EDIT:

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