You can create as many materialized views as you want. There are several different approaches to how the materialized view is generated, but the basic idea is that every time we update application data, we also update any materialized views that depend on that data. We build a new "view" of the data that stores the data in just the right way to support a particular query. The materialized view pattern is a simple idea. Whether you're storing your data in a relational database like SQL Server or a document database like Cosmos DB, there are going to be occasions where the queries you want to run are simply too slow and costly. In the real world, unfortunately, that's just not possible. No matter what question we asked of the data, it would respond quickly and efficiently. In an ideal world, we'd store all of our data in a database that was perfectly optimized for every query we threw at it. Let's start with a brief overview of what is meant by a "materialized view". Be sure to check out the other great contributions to this series. I've written this as my submission to the " Serverless September" initiative. In this article I want to discuss the materialized view pattern and why I think serverless is a good match for it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |