Materialized Query Table in SQL Server 2005

Question

In DB2 there is a support for Materialized Query Table (MQT). Basicly you write a query and create a MQT. But the difference from View is that the query is pre-executed and resulting data is stored in MQT and there are some options when to refresh/syncronize the MQT with base tables.

I want same functionality in SQL Server. Is there a way to achieve same result?

I've tables with millions of rows, and I want to show summary (like total # of members, total expense and etc) in dashboard. So I don't want to count every time user gets to dashboard, instead I want to store them in table and I want that table to be refresh each night.

Any kind of hints, answers,suggestions and ideas are welcome. Thanks.

Answer 1

Materialized views are based on a source table (or tables), and will update their data immediately when the source table(s) are updated. This is a powerful feature, but based on discussion on the prior posts it does not sound like what you want or need.

A simple way to do what you want is to:

• Create a separate table to contain the aggregated (summarized) data
• Write a process (preferrably a stored procedure) to calculate and store that data
• Determine how and when to launch this procedure

Does the summarized data need to be prepared at (or "as of") a specific time, such as 12:01am? If so, create a SQL Agent job and configure it to launch the procedure at 12:01am. Can the summarized data only be prepared after a prior routine or two has prepared or finalized the preceding day's data? If so, add a call to the summarizing routine at the end of that process.

(How would this be configured this in DB2? How do you determine or configure when an MQT is refreshed?)

Answer 2

It seams that Indexed View doesn't pre-execute query and store it's result and does not give refresh options.

But absolutely it does!!

An "indexed view" is a materialization of a view in SQL Server - the resulting data is assembled and stored on disk. So the query is pre-executed, in that sense.

And no, you don't have to index on every field -- just the fact you're adding a clustered index to the view (based on a suitable column) actually stores the resulting data to disk. In SQL Server, the clustered index is the data, really.

Check out this article in SQL Server 2000 Books Online: Creating an Indexed View

Microsoft clearly writes:

When a unique clustered index is created on a view, the view is executed and the result set is stored in the database in the same way a table with a clustered index is stored.

Answer 3

Yes, look at this article http://msdn.microsoft.com/en-us/library/cc917715.aspx about "Indexed view"

and look also at (WITH SCHEMABINDING) option

Answer 4

What Do You think abaut Replication, They said that almost every business scenario considering replication for data reporting