Materialized Views:
A materialized view in a relational database management system (RDBMS) is a database object that stores the results of a query as a precomputed table. Unlike regular views, which are virtual and dynamically computed at query time, materialized views physically store the results, allowing for faster query performance by eliminating the need to recompute the result set every time the view is accessed.
Purpose and Use:
Materialized views are used to improve query performance, especially in scenarios where complex and resource-intensive queries need to be executed frequently. By precomputing and storing the results, materialized views reduce the overhead of executing the underlying query repeatedly, thus enhancing overall system performance. They are particularly beneficial in data warehousing environments, where large volumes of data are involved, and query performance is critical.
When to Use:
Materialized views are useful in situations where:
- Query performance is a priority, and there are frequently accessed or resource-intensive queries.
- The underlying data doesn't change frequently, or the cost of refreshing the materialized view is acceptable compared to the performance gain.
- Aggregation, summarization, or joins are involved in the queries, as materialized views can store the precomputed results of these operations.
When Not to Use:
Materialized views may not be suitable in scenarios where:
- The underlying data changes frequently, leading to the need for frequent refreshes of the materialized view, which can impact system performance.
- The storage requirements for maintaining materialized views become prohibitive, especially for large datasets.
- Real-time or near real-time data access is required, as materialized views store static snapshots of data rather than dynamically computed results.
Behavior in Different RDBMS:
Behavior of materialized views can vary across different RDBMS. Here's a brief overview:
- Oracle: Oracle supports materialized views and provides a rich set of features for their creation, management, and refresh. Syntax for creating materialized views involves the
CREATE MATERIALIZED VIEW statement. - PostgreSQL: PostgreSQL also supports materialized views with similar syntax to Oracle. Materialized views are created using the
CREATE MATERIALIZED VIEW statement. - MySQL: MySQL does not have built-in support for materialized views. However, similar functionality can be achieved using scheduled jobs or triggers to periodically refresh pre-computed query results.
Example in Oracle DBMS:
Let's consider an example scenario in Oracle DBMS:
- Create Sample Table:
CREATE TABLE sales (
product_id NUMBER,
product_name VARCHAR2(50),
quantity_sold NUMBER,
sale_date DATE
);
- Insert Sample Data:
INSERT INTO sales VALUES (1, 'Product A', 100, TO_DATE('2024-01-01', 'YYYY-MM-DD'));
INSERT INTO sales VALUES (2, 'Product B', 150, TO_DATE('2024-01-02', 'YYYY-MM-DD'));
INSERT INTO sales VALUES (3, 'Product C', 200, TO_DATE('2024-01-03', 'YYYY-MM-DD'));
- Create Materialized View:
CREATE MATERIALIZED VIEW mv_sales_summary
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
AS
SELECT product_id, SUM(quantity_sold) AS total_quantity
FROM sales
GROUP BY product_id;
In this example, we create a materialized view called mv_sales_summary that summarizes the total quantity sold for each product from the sales table. The materialized view is set to refresh immediately (ON COMMIT) after any transaction that changes the base table data. This ensures that the materialized view always reflects the latest data from the sales table, providing efficient querying capabilities.
You can create a materialized view without specifying the refresh method, and then later manually refresh it using the DBMS_MVIEW package. Here's how you can create the materialized view without specifying the refresh method and then manually refresh it.
CREATE MATERIALIZED VIEW mv_sales_summary
BUILD DEFERRED
AS
SELECT product_id, SUM(quantity_sold) AS total_quantity
FROM sales
GROUP BY product_id;
In this example, the materialized view mv_sales_summary is created without specifying the refresh method, meaning it won't be refreshed automatically.
To manually refresh this materialized view, you can use the DBMS_MVIEW.REFRESH procedure. Here's how you can do it:
BEGIN
DBMS_MVIEW.REFRESH('mv_sales_summary');
END;
This PL/SQL block calls the DBMS_MVIEW.REFRESH procedure, specifying the name of the materialized view (mv_sales_summary) as the parameter. When executed, this procedure refreshes the materialized view, updating it with the latest data from the base tables.
You can schedule this manual refresh operation to occur at specific intervals using a job scheduler or execute it whenever necessary based on your application requirements.
.png)
.jpg)