63

I'm new to Oracle databases. If I have understood correctly, materialized view is a view which result set is saved as a physical table in the database and this view/table is refreshed bases on some parameter. If view is saved as a physical table, why not store the data into a table in the first place? So what is the benefit of using materialized view instead of a table?

Improve this question

6 Answers 6

Reset to default
67

One of the biggest benefit of using a materialized view is that Oracle takes care of keeping the data in sync. If you have a separate aggregate table, you are responsible for keeping the data synchronized. That generally requires a reasonable amount of code and a decent amount of testing and most organizations manage to make mistakes that leave holes that cause the aggregate table to get out of sync. This is particularly true when you try to implement incremental refreshes of the aggregate table.

Another major benefit is that, depending on the settings, Oracle can use query rewrite to use materialized views when users issue queries against base tables. So, for example, if you have a bunch of existing reports against a detail table that produce daily, monthly, and yearly aggregate results, you can create a materialized view on the base table that aggregates the data at a daily level and the optimizer can utilize that materialized view for all your existing queries. This makes it much easier to optimize reporting workloads in a data warehouse without trying to go and rewrite dozens of reports to use your new aggregate table or to mess with DBMS_ADVANCED_REWRITE to force your own rewrites of the queries.

Improve this answer
2
14

Materialized Views are automatically updated as their base tables are updated.

Improve this answer
1
  • 2
    Note that ON DEMAND is the default refresh behavior. The materialized view must be created with ON COMMIT. and maintaining the materialized view isn't free. It's probably cheaper than a trigger, though.
    – durette
    Oct 14, 2016 at 22:03
10

One good case for using MVs is that some times you want to aggregate data and get this summary information from large tables frequently and quickly. Without materialized views, you have to either deonormalize some of your tables and maintain the aggregates via code or repeatedly scan large sets of rows. Either way is not always acceptable specially with dashboard and similar online applications. If you keep the results in a separate tables, you complicate your application code and as @Justin Cave says, you will be in charge of making sure that the manually aggregated data is in synch. with the original table's data.

Improve this answer
4

Not an Oracle person, but another use case would be third party solutions. They generally do not support you making changes to their designs but a MV would be "invisible" to their code but provide access to custom reporting/data extracts.

It's not free in that it will cost have storage costs and potentially impactful insert/update time costs but that may be offset by the time spent retrieving the materialized data versus a "straight view" or creating actual tables and maintaining the surrounding ETL.

Finally, doing so may void your support contract with the vendor, consult-your-lawyer-blah-blah-blah

Improve this answer
0
3

Instead of going directly to Materialized views let me explain Views.

Basically views are exist logically unlike tables. If we want to hide certain columns to users we can not do using tables. Creating a view we can achieve the security.

Use-case: if a view is internally related with 10 tables along with group by and functions have millions of rows, it takes much time to execute.

So here comes Materialized views helps us to get data faster. Materialized views are physically exist in database. Whenever the base table is updated the Materialized view gets updated.

Materialized views are updated periodically based upon the query definition, table can not do this.

Improve this answer
0

A materialized view can be set up to refresh automatically on a periodic basis. A table may need additional code to truncate/reload data.

example: Materialized view having data from multiple tables can be setup to refresh automatically during non-peak hours. A physical table would need additional code to truncate/reload data.

Security can be better controlled in a materialized view rather than a table.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.