Abdu's Blog

Understanding Views and Materialized Views in Databases

Abdelrahman Gamal's photo
Abdelrahman Gamal
·

3 min read

Table of contents

Hey folks, When working with databases, we often deal with complex queries, joining multiple tables to retrieve specific data. Repeating such queries every time we need the same data can be inefficient. This is where views come into play, acting as a kind of "query wrapper" that simplifies data retrieval.

What Are Views?

A view is essentially a virtual table. It is not a physical table that stores data but rather a named query that dynamically fetches data when you access it. Think of it as a predefined SQL query that you can call whenever needed.

For example, instead of rewriting a complex query multiple times, you can save it as a view and retrieve data using a simple SELECT statement.

Key Characteristics of Views:

  • Views are read-only in most cases, meaning you can query data (SELECT) from them but cannot perform INSERT, UPDATE, or DELETE operations on them. This is because they do not store data—they only define how data should be retrieved.

  • They simplify the structure of complex queries by encapsulating the logic into a reusable object.

Example of Views:

Imagine you have two tables:

  1. employees: Contains attributes like employee_id, name, and department_id.

  2. departments: Contains attributes like department_id and department_name.

You frequently need a list of employee names along with their department names. Instead of writing this SQL query every time:

SELECT e.name, d.department_name 
FROM employees e 
JOIN departments d 
ON e.department_id = d.department_id;

You can create a view called employee_department:

CREATE VIEW employee_department AS
SELECT e.name, d.department_name 
FROM employees e 
JOIN departments d 
ON e.department_id = d.department_id;

Now, instead of rewriting the complex query each time, you can simply use:

SELECT * FROM employee_department;

Introducing Materialized Views

While standard views dynamically fetch data every time they are accessed, materialized views take a different approach. They store the results of a query as a physical table, effectively caching the data.

When to Use Materialized Views?

Materialized views are ideal for scenarios where:

  • The data doesn't need to be real-time.

  • You can tolerate slight delays in data updates (e.g., daily refreshes).

  • Performance is critical, and you want faster access to precomputed results.

For example, imagine you have a complex query that aggregates sales data across multiple tables. Instead of running this query every time you need the report, you can store the results in a materialized view. You can then create a scheduled job to refresh the data periodically, such as once a day or once a week, ensuring the data remains relatively up-to-date.

Key Characteristics of Materialized Views:

  • They store query results in a physical table, making data retrieval much faster.

  • They need to be refreshed explicitly (manually or via scheduled jobs) to keep the data up-to-date.

  • Unlike standard views, materialized views consume storage because they physically store data.

SQLDatabases