When an indexed view is not an option..
I am wondering how I should most quickly fetch the data from a group of tables for reporting / viewing.
My tables are slowly changing, meaning that I use a getDate() function to pull the right records between effective and expire dates. An admin may be making changes occassionally to some records, but mostly the data is read-only by site visitors. It's ok for the changes made by the admin not to go live immediately, of if urgent, for them to click a button or something to force them live.
I have a big query which brings a dozen tables together and can be a bit slow.
It includes case statements and left joins and getDate() which not allowed in Indexed Views.
I'm wondering if it makes sence to create a table that I populate from my big query, add various indexes to the table and populate it every night or every few hours or something. Are there downsides to this? It seems indexed views are not an option...
My tables are slowly changing, meaning that I use a getDate() function to pull the right records between effective and expire dates. An admin may be making changes occassionally to some records, but mostly the data is read-only by site visitors. It's ok for the changes made by the admin not to go live immediately, of if urgent, for them to click a button or something to force them live.
I have a big query which brings a dozen tables together and can be a bit slow.
It includes case statements and left joins and getDate() which not allowed in Indexed Views.
I'm wondering if it makes sence to create a table that I populate from my big query, add various indexes to the table and populate it every night or every few hours or something. Are there downsides to this? It seems indexed views are not an option...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I haven't got much experience with Oracle. The main idea of indexed views in SQL is so that when a query refers to tables, if there is pre-joined indexed view that already has the answer, it automatically goes to the indexed view, without a code change. Is that the way Oracle materialized views work?
Couldn't you use the GETDATE() outside the indexed view? or is it more complicated than that?
i.e. you create an indexed view that satisfied everything in your query (joins, summarys, but no getdate()). Then run your normal select (including GETDATE())
You'll have to experiment but its probably worth
1. Creating an indexed view as close as possible to your query
2. Run your original query and check the execution plan (CTRL-L)
3. See if the execution plan refers to your indexed view
You may get a little performance increase even if you can't code the whole lot in the view.
There are other things you can do to increase performance like set the database file to read only, mess with disk I/O, stuff like that.
Couldn't you use the GETDATE() outside the indexed view? or is it more complicated than that?
i.e. you create an indexed view that satisfied everything in your query (joins, summarys, but no getdate()). Then run your normal select (including GETDATE())
You'll have to experiment but its probably worth
1. Creating an indexed view as close as possible to your query
2. Run your original query and check the execution plan (CTRL-L)
3. See if the execution plan refers to your indexed view
You may get a little performance increase even if you can't code the whole lot in the view.
There are other things you can do to increase performance like set the database file to read only, mess with disk I/O, stuff like that.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
kselvia, that's a very clever idea !
I would only need to change the value of the WHdate nightly as time is not a factor.
I have tried, however, to create an indexed view in another, less complex, situation and found it nearly impossible. Indexed Views have so many restrictions it's incrediblely difficult to make any use of them at all; no unions, no case statements, nothing inside of count(xxx), no 'distinct' or left joins (i think).
What a nightmare !
But I wonder if your suggestion about the WHdate would help speed up regular queries or views rather than using getDate() ?
Thanks!
I would only need to change the value of the WHdate nightly as time is not a factor.
I have tried, however, to create an indexed view in another, less complex, situation and found it nearly impossible. Indexed Views have so many restrictions it's incrediblely difficult to make any use of them at all; no unions, no case statements, nothing inside of count(xxx), no 'distinct' or left joins (i think).
What a nightmare !
But I wonder if your suggestion about the WHdate would help speed up regular queries or views rather than using getDate() ?
Thanks!
Using WHdate in other queries would not be faster than using getdate(). Chances are it may even hurt performance.
As nmcdermaid said, it seems you could utilize an indexed view to generate a basis from which to make further queries which CAN have your aggregates, cases, etc.
Are you pretty confident your existing tables have the proper indexes for the kinds of reports/complex queries you are running?
Maybe there are tuning opportunities there.
As nmcdermaid said, it seems you could utilize an indexed view to generate a basis from which to make further queries which CAN have your aggregates, cases, etc.
Are you pretty confident your existing tables have the proper indexes for the kinds of reports/complex queries you are running?
Maybe there are tuning opportunities there.
Actually the seperate table thng is along the lines of a calendar table.. you have a flag for current date, and you have another two dozen flags for same day lastweek, same day last year, week to date etc.
I recall now that the oracle equivalent of indexed views is query rewrite.
I recall now that the oracle equivalent of indexed views is query rewrite.
Futher to that, if you are indeed creating a data warehouse, then all of your case statements, outer joins etc. would have already been processed, and no complex queries would be required.
It sounds like many of your issues would be satisfied with a data warehouse.
It sounds like many of your issues would be satisfied with a data warehouse.
ASKER
Thanks for the great information.
ASKER
Thanks for your response.
Although numbers are involved, the numbers are not totalled or averaged in any way, so I htink data warehousing is the way to go.
I understand how to denormalize the data with indexes for faster quering. I am wondering, however, if there are specific SQL Server 2005 features or special data definitions that I need to look for in order to accomplish this. Or am I basically building the tables and indexes and that's the meat of it.
Also, does SQL Server 2005 have anything like Oracle's Materialized Views? I've heard that Indexed Views are Microsoft's answer, but they aren't even close. You may not be familiar with Oracle, but I'm wondering if there are other SQL Server options that I am not aware of take "snap shots" of the data.