Other than the word "view" in their names and the fact that both are defined by an underlying SQL, there is little else common between Oracle views and materialized views – yet they can be a source of great confusion if you are new to these database objects.
Here’s a summary of the key differences between views and materialized views, to put an end to all mix-ups. By the end of the article, you should be in a position to decide if your specific scenario needs a view, a materialized view, or neither.
1. Moment Of Execution
A view’s SQL is executed at run-time. The results are fetched from the view’s base tables when the view is queried.
A materialized view (called snapshot in older Oracle versions) is a "pre-answered" query – the query is executed when the materialized view is refreshed. Its result is stored in the database and the query only browses the result.
2. Space
A view occupies no space (other than that for its definition in the data dictionary).
A materialized view occupies space. It exists in the same way as a table: it sits on a disk and could be indexed or partitioned.
3. Freshness of Output
A view’s output is built on the fly; it shows real-time data from the base tables being queried.
A materialized view does not reflect real-time data. The data is only as up to date as the last time the materialized view was refreshed.
4. Where To Use
A view is best used when:
- You want to hide the implementation details of a complex query
- You want to restrict access to a set of rows/columns in the base tables
A materialized view is best used when:
- You have a really big table and people do frequent aggregates on it, and you want fast response
- You don’t mind the result being a little out of date, or your application data has more queries than updates (as in a BI/data warehousing system)
Caution!
Are you creating a materialized view to avoid the pain of tuning a query? Don’t do it! A materialized view brings with it the overhead of maintaining extra DB objects that need regular refresh besides giving you out-of-date data, all for something that might have been fixed by writing better code.
Whether your query runs directly on tables, on views or via materialized views, it must be the most efficient query possible.
Materialized views are NOT a quick fix for bad code.
{ 17 comments… read them below or add one }
Good comparision for a quick outline….Really helpful….Great work
A very good, detailed comparison..It really helps to understand..Appreciate It..Keep Going
Glad to be of help.
good comparision .It’s helpful thanks.
Thanks Rashi.
It’s very helpful and the way write it’s very interesting.
Please I wanna know this type of knowledge sharing in Data Warehousing and Informatica.
Please help me.
Really awesome
Really awesome helpfull great job keept it up.
Really super blog, as a learner i am learning a lot here. I want you people to cover all the topics in pl/sql.
Article is well refined & precise. Thanks for sharing such wonderful knowledge. Keep sharing……
Very useful comparison. keep posting….
Great comparison between View and Materialized Views(Snapshoots). It gives me better idea ever before.
It’s very helpful to me……..Thank u very much
Good article but I was puzzled by your last line of the artcile “Materialized views are NOT a quick fix for bad code”.For example in our company there are lakhs of accounts where the history of those accounts maintained in a table.They need to get txn details for a customer for previous day.what sort of better code one could write.
@Naveen: That last line is to be read in the context of the preceding lines about poorly performing SQL, the blanket “resolution” for which – as I see sometimes – is to create an MV.
MVs are not meant to bypass SQL optimization.
The example you mention does not need real-time data but the previous day’s. It may be fine to use an MV there.
way of describe is very good. now i understood difference between view and materialized view .
It’s very helpful to me……..Thank u very much