Создать индекс в представлении 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 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. 

Мои вопросы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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