View And Materialized View

Difference Between View and Materialized View

In this blog, let’s delve into the comparison between the concepts of Materialized View vs View 

Views are a fundamental concept in database management systems and are often a common topic in interviews. It is one of the most asked questions, similar to discussions about concepts like truncate vs. delete, correlated vs. non-correlated subqueries, or primary keys vs. unique keys. In this tutorial, we will explore the distinction between views and materialized views.

The original table in a database is typically stored in physical memory, and users can access all its attributes by running queries. However, there are scenarios where we need to restrict users from accessing certain data within the table and only allow them to retrieve specific attributes. 

For example, consider a student table where users should be able to search for student names, marks, branches, ages, and other information, but they must not be allowed to retrieve mobile numbers and addresses of the students.

In such cases, it’s a practical approach to create a view that acts as a virtual table. This view can display only the required attributes of the table, effectively limiting what users can access. Additionally, materialized views provide similar functionality, but they store a physical copy of the data, which can be beneficial for certain use cases.

Let’s delve into the fundamentals of views and gain a better understanding of this concept.

What is View?

A view can be described as a virtual representation of a relation, and it functions like a real table within the database system, even though it’s not considered a part of the logical relational model. To create a view, you use the “CREATE VIEW” command, which constructs a virtual table containing data derived from a query expression.

It’s important to note that the result of creating views is not permanently stored on the disk. Instead, when data is needed, users must execute a query, and the view is computed in real-time. Consequently, every time the view is accessed, it offers the most recent and up-to-date data from the original tables. 

In short, a view isn’t a physical storage entity on the disk; it’s a dynamic computation that takes place each time it is used or accessed.

The performance of a view is primarily influenced by the specific query it’s based on. If you aim to enhance the overall performance of a view, there are a couple of strategies to consider. First, you may want to minimize the use of join statements in your query. 

Alternatively, if your query involves multiple joins between tables, it’s advisable to utilize columns with indexing. Index-based columns tend to deliver better performance compared to non-indexed columns when working with multiple joins.


Create View A AS <Query Expression>

Advantages of View

  • Views offer a way to simplify large base tables, allowing us to create virtual tables tailored to specific data needs.
  • By joining one or more tables, views can be easily defined to bring together relevant information.
  • Views serve to hide the intricacies of underlying data, presenting a more straightforward and user-friendly perspective.
  • Views enable us to control the extent of exposure of underlying tables to external users, ensuring that sensitive or complex data remains hidden from the outside world.

What is Materialized View?

A materialized view represents a physical, static copy of the original base tables, much like a snapshot or image of the base table’s content. When you create a materialized view using the “CREATE MATERIALIZED VIEW” command, it contains data retrieved from a query expression.

This materialized view is stored on disk and is precomputed as an object. Unlike regular views, it doesn’t automatically refresh with each access. Instead, it necessitates manual updates in the event of changes, typically achieved using triggers, a process known as “Materialized View Maintenance.”

When we compare the two, materialized views are incredibly fast in their response. This is because materialized views are pre-computed and stored on disk. Consequently, they don’t need to spend extra time resolving queries each time, making materialized views significantly faster than standard views.

Materialized views are especially valuable when time-saving in query computation is crucial, and they are frequently employed in data warehousing scenarios. Updating a materialized view can be accomplished through three primary methods, as follows:

  • A materialized view is initially updated when its relation is defined.
  • It can also be updated each time it is accessed
  • Alternatively, materialized views can be set to update periodically at specified intervals.

Advantages of Materialized View

  • Materialized views can significantly enhance the overall performance of queries, especially when these queries repeatedly utilize the same sub-query results.
  • Materialized views offer transparency and are automatically maintained with the assistance of a background service called Snowflake. This service ensures that materialized views are kept up-to-date following any changes within the database, minimizing the likelihood of errors and providing efficient results compared to manual updates.
  • Data accessed through materialized views remains current, no matter how frequently changes occur in the database system. Whenever a query is executed, Snowflake retrieves the most recent data and updates the materialized views automatically.

Comparison between Materialized View Vs View

Following are the significant Differences between View and Materialized view.

Storage on Disk:

  • Views: Views are like dynamic lenses into your data. They are not physically stored on the disk, which means that every time you query a view, it recalculates the result based on the underlying data. This duality can be seen as both an advantage and a disadvantage. On the one hand, it ensures that you always see the most up-to-date data, but on the other, it can be computationally expensive, especially with large datasets or complex queries.
  • Materialized Views: Materialized Views, in contrast, are like snapshots of your data that are stored on the disk. They provide a static representation of the data at the time of their last update. This static nature allows for faster retrieval as there’s no need for real-time computation.

Update Timing:

  • Views: When you access a view, it retrieves data from the source tables, computes the result, and presents it to you. Therefore, views are updated each time they are accessed.
  • Materialized Views: Materialized Views are updated when they are created, and they don’t need to be recomputed each time they are accessed. They can be updated periodically or when certain events trigger an update.

Data Refresh:

  • Views: When you query a view, you get the most current data from the source tables. This dynamic behavior ensures that the data is always up-to-date.
  • Materialized Views: Materialized Views do not automatically refresh when queried. Users need to trigger a refresh manually or set up a mechanism to update them automatically.

Copy of the Original Table:

  • Views: A view does not create a separate copy of the table. It provides a logical representation of the data based on the query used to define the view.
  • Materialized Views: Materialized Views create a physical copy of the data, which can be considered a separate table containing a snapshot of the data from the moment of the last update.


  • Views: Views are essentially virtual tables created as a result of a query expression. They don’t physically store any data but instead define how the data should be presented.
  • Materialized Views: Materialized Views are tangible copies of the data. They store the actual data from the underlying tables, like a physical snapshot of a specific query’s result.

Row ID:

  • Views: Views preserve the same row IDs as the original table. In other words, the rows in a view correspond directly to the rows in the base table.
  • Materialized Views: Materialized Views often have a different set of row IDs, which can be independent of the original table. This can be particularly helpful for partitioning and managing large datasets.


  • Views: Due to their real-time computation and lack of physical storage, views can be slower, especially when dealing with complex or resource-intensive queries.
  • Materialized Views: Materialized Views, stored on disk, offer better performance, particularly when queries require repetitive access to the same data. The stored data is readily available, resulting in faster query response times.

Automatic Updates:

  • Views: Views update automatically when they are accessed. This ensures that you always see the most recent data, but it can impact performance.
  • Materialized Views: Materialized Views require manual triggers or scheduled processes (like triggers or background services such as Snowflake) to update the stored data. This manual control can be advantageous for maintaining data consistency.

These detailed explanations on “Materialized View vs View” will provide a comprehensive understanding of the differences between Views and Materialized Views, helping you make informed decisions in your database design and query optimization.


In conclusion, views play a pivotal role in data retrieval. Throughout this tutorial, we’ve defined both views and materialized views, highlighting their key advantages. 

We’ve also provided practical examples to illustrate these concepts. Armed with this knowledge, you can now grasp the fundamental distinctions between these two approaches and make informed choices based on your specific requirements.

If you’re looking to explore the differences between views and materialized views in SQL, and want to enhance your database knowledge, consider taking our SQL training course! Get started today to master this essential skill and level up your database management expertise. 

Join our SQL Training in Chennai to gain a deeper understanding of views and materialized views in SQL. Don’t miss this opportunity to boost your SQL proficiency.

Leave a Comment