Comments on: SQL SERVER – UNION Not Allowed but OR Allowed in Index View – Limitation of the View 6

By: SQL SERVER – Weekly Series – Memory Lane – #008 « SQL Server Journey with SQL Authority

Sat, 22 Dec 2012 01:32:17 +0000

[...] UNION Not Allowed but OR Allowed in Index View – Limitation of the View 6 [...]

By: SQL SERVER – Indexed Views and Restrictions – Quiz – Puzzle – 7 of 31 « SQL Server Journey with SQL Authority

Sun, 08 Jan 2012 01:30:55 +0000

[...] – Limitation of the View 7 SELF JOIN Not Allowed in Indexed View – Limitation of the View 9 UNION Not Allowed but OR Allowed in Index View – Limitation of the View 6 Keywords View Definition Must Not Contain for Indexed View – Limitation of the View [...]

By: Simon Watkins

Simon Watkins — Fri, 16 Dec 2011 15:40:46 +0000

Why could you not use GROUP BY in your indexed view to eliminate duplicates (obviously remembering to include the mandatory COUNT_BIG(*) AS [COUNT]). Is this a hack? I want to put it into production code, so if anyone has any reason to expect risk in doing this, then please let me know…

Also worked around the lack of a MAX operation in indexed views by using a Tally Table and COUNT_BIG. Have since replaced this terrible hack, in my code, with a TOP (1) WITH TIES … ORDER BY ROW_NUMBER OVER (PARTITION BY ….) operation, as it is not only faster (with the correct indexes), but it doesn’t take the lifetime of an average main sequence star to compute, and it is not a hack.

By: SQL SERVER – Interview Questions and Answers – Frequently Asked Questions – Data Warehouseing Concepts – Day 20 of 31 Journey to SQLAuthority

Wed, 20 Jul 2011 01:31:37 +0000

[...] (Read More Here) [...]

By: Duncan

Duncan — Wed, 06 Oct 2010 10:25:46 +0000

As I understand it, it’s about updateability. If you have UNION ALL, SQL Server would need to be able to determine which branch of the UNION statement was affected by an update to one of the underlying tables. My guess is that it is tricky to do so, and therefore UNION ALL is not allowed. UNION (without the all) isn’t allowed for the same reason that DISTINCT isn’t allowed. That’s easier to understand, since it allows a single row in the view to be decomposed from multiple branches of the UNION, so an update to any of the tables could result in extra rows in the views, or fewer. Again, a bit difficult for the query processer to, er, process.

I haven’t found any definitive answers though, so can you enlighten us??!!

By: gifts vizag

gifts vizag — Sun, 03 Oct 2010 06:09:49 +0000

So far I did not think about limitation on Union as I did not work much in Views. Great article.

By: Marko Parkkola

Marko Parkkola — Thu, 23 Sep 2010 05:01:57 +0000

Just one more thing. IIRC your can update the data in indexed view with normal insert/update operation. Now because indexed view acts almost like a normal table, which is constructed from other tables, things get impossible if there’s duplicate records in those tables. Which one to update?

By: pinaldave

pinaldave — Thu, 23 Sep 2010 03:19:45 +0000

Great Answer.I was waiting for someone to talk about it. Another hint : Effect of Distinct on NULL.

By: Michael

Michael — Thu, 23 Sep 2010 03:06:55 +0000

I have to figure one of the reasons that UNION isn’t allowed is because DISTINCT isn’t allowed, and UNION performs a DISTINCT operation automatically. But that isn’t the only reason because a UNION ALL isn’t allowed either.

By: Marko Parkkola

Marko Parkkola — Wed, 22 Sep 2010 18:57:54 +0000

Well, I came up with many reasons but when I started to think about them in depth I figured out ways to work around them. I might guess that there is no technical reason why UNION could not be used in indexed view but I would guess that it would slow down the system so much that it would negate all the positive effects of indexed view.

IIRC Microsoft has left out some features from Sql Server for performance reasons.

If you absolute want to use UNION in indexed view I came up with a workaround but it’s a messy one. Create a normal table (with primary key) which is used as “indexed view”. Create trigger(s) to actual data table(s) and do data update “by hand” to the indexed-view-table. Hmmm… I think I just reinvented denormalization :)

By: pinaldave

pinaldave — Wed, 22 Sep 2010 06:30:50 +0000

Very true. I agree.

As I said at the bottom that in this case only this works. Now try DISTINCT in Index View – it will not work. Another limitation of the VIEW!

I just think the limitations are endless.

Kind Regards,
Michael

By: Michael

Michael — Wed, 22 Sep 2010 05:52:38 +0000

The two versions of the view aren’t actually the same. With your sample data they return the same results, but for them to always return the same results you would have to add a DISTINCT to your second version:

ALTER VIEW SampleView
WITH SCHEMABINDING
AS
SELECT DISTINCT ID1,ID2,SomeData
FROM dbo.mySampleTable
WHERE ID1 < 1000 OR ID2 < 1000;
GO

By: siva

siva — Wed, 22 Sep 2010 02:07:14 +0000

Hi Pinal Dev,

I am not understand

altered view then the clusted index is created why ?

what is the reason. could you please explaine any body.