I am trying to create an index on the following view:
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
I am getting the following error:
Msg 1939, Level 16, State 1, Line 2
Cannot create index on view '_Source' because the view is not schema bound.
I added WITH SCHEMABINDING to the CREATE and now get the following error:
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.
My questions are:
How would I create an index on this view? Would creating separate indexed views really work?
Lastly, am I really going to see a performance improvement for any queries that may JOIN this view?
Thanks in advance!
Save this question. Show activity on this post. While each of both select statements takes less than 1 second when executed separately.
Union will be faster, as it simply passes the first SELECT statement, and then parses the second SELECT statement and adds the results to the end of the output table.
Views make queries faster to write, but they don't improve the underlying query performance. However, we can add a unique, clustered index to a view, creating an indexed view, and realize potential and sometimes significant performance benefits, especially when performing complex aggregations and other calculations.
You cannot create an index on a view that makes use of a union operator. Really no way around that, sorry!
I would imagine you've seen this, but check out this MSDN page. It gives the requirements for indexed views and explains what they are and how they work.
As to whether or not you'd see a performance benefit if you COULD index the view, that would depend entirely on the size of your tables. I would not expect any impact on creating separate indexed views, as I would assume that your tables are already indexed and you aren't doing any joining or logic in the view.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With