Equivalent of Materialized Views in SQL Server

Question

Hi
we are migrating  Oracle Database to SQL Server 2012 and is looking for solution, equivalent to Materialized Views in Oracle.
we had tried to implement indexed View, but that was not possible, because the MVs have outer joins, subqueries, aggregate functions and also there is no column in it which can act as a Primary Key.
Please Help to get a solution for this issue.
Regards
Joyasree Mondal

Answer 1

>use tempdb
>drop table t
>go
>create table t(id int, constraint pk_t primary key (id))
>
>go
>insert into t(id)
>select top 1000 cast( cast( newid() as binary(4) ) as int)
>from sys.objects o, sys.columns c
>go 100
>
>
>select id
>from t with (index=pk_t, tablockx)
>
>
>select id
>from t with (index=pk_t, nolock)
Still the same order.
>> No, its always in the key order like I've shown here.
> You are extrapolating from a single example.
Actually, this information doesn't even come from my exampleS (there were quite a few so far). Its written in the article you posted here. My examples are meant to confirm that and explain why the ORDER BY clause is redundant in some cases.
> I have.  ORDER BY in a view used to always return ordered results.  Then it didn't.
Examples? References?
>GROUP BY without an ORDER BY used to always return ordered results.  Then it didn't.  Many queries have >change the result ordering when you get a parallel plan.
Now you finally admit ordered results would always be returned, even without an order by clause. We are in the right track it appears. The reason for this change of behavior is a variation in the logical operator used by the query optimizer, and not the
way the engine reads pages from disk.
In the beginning of times there was stream aggregate, an operator that would require its input to be sorted. And this is how a GROUP BY clause would ensure results were always ordered.
But then his ugly cousin came and messed things up. He doesnt need an ordered input so yeah, order would be random. AGAIN, there are still ways of enforcing order here, through query hints, without requiring an order by clause, so this changes nothing.
You have confirmed that for a given operator, results will always be ordered. Your own argument has, once again, proven my point.
> Right.  But there are different _kinds_ of scans.  An ordered scan, where SQL Server reads rows based on the logical order of the index is just one kind. 
It only won't scan in key order (by scheduling reads) if you change the transaction isolation level and hope for the worse. Because the key order scan is the best performing way of reading pages, this behavior (although possible) wasan't even observed in
the example with NOLOCK/TABLOCK (known to cause allocation-order scans in larger tables) you posted above.
> Other kinds include the parallel scan, the reverse scan,
References?
> the merry-go-round scan,
Only applies to table scans, not indexes.
http://technet.microsoft.com/en-us/library/ms191475%28v=SQL.105%29.aspx
> And the allocation-order (or unordered) scan. 
Only if you specify TABLOCK or NOLOCK query hints, which I haven't done. This is something that goes without saying, it's irrelevant to an indexed view scenario such as this one.
Some people have also said it will perform an allocation-order scan if the index is too fragmented in SQL Server 2005, but as of 2012 it (probably) won't, as I have shown here. There is also no document anywhere in the internet (you are free to search for
it), that would point us otherwise. If you have access to additional information, I would be more than happy if you could share it with us.
Reference: http://sqlmag.com/database-development/quaere-verum-clustered-index-scans-part-iii
> And don't take my word for it.  Take Conor Cunningham's:
>If you need order in your query results, put in an ORDER BY.  It's that simple.  Anything else is like >riding in a car without a seatbelt.
>No Seatbelt - Expecting Order without ORDER BY
Again, with all due respect, did you read your own article? Did you read what I said earlier about having multiple I/O threads as a whole other situation? If you add new variables, OF COURSE the results will be different. Parallelism was disabled in the
server I performed these tests on, but still you can control this by query hints, and you can enforce execution plans by using plan gudes.
Its like I always say - it's always about the 0.001% of situations, the exceptions, rather than the general rule.
Tell Mr Connor to add MAXDOP 1 to his querys OPTION clause and see if results are still unordered lol
References:
http://msdn.microsoft.com/en-us/library/ms190417.aspx
http://msdn.microsoft.com/en-us/library/ms181714.aspx
http://technet.microsoft.com/en-us/library/ms188611%28v=sql.105%29.aspx
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2008/08/27/no-seatbelt-expecting-order-without-order-by.aspx
Imagining uncontrollable factors that would get an ordered input to be retrieved in an unordered manner is one of SQL Server's myths. There are a whole other people around who think the same way because of some experiences they had when they didn't know
how to control the execution plan, and adding an order by clause is a very popular and easy shortcut to a complex problem. "In the worst cases it will just be redundant", they say. What they like to forget is that sorting has an often high cost,
and it can be avoided by taking advantage of indexes.