Let's now discuss a powerful feature of MongoDB, Views. MongoDB enables non-materialized views, meaning they are computed every time a read operation is performed against that view. They are a way to use an aggregation pipeline as a collection. From the user perspective, views are perceived as collections, with some key differences we'll go over later in the lesson. So what might views be useful for? Suppose we're a large financial institution with customers with different tiers. We've just recently launched a big promotion in our conducting a phone campaign. We've hired a temporary staffing agency with several regional offices. We'll assign a different tier to each regional office. This is a sample of one record from our customer's collection. As we can see, there is sensitive and potentially biasing information that we do not want to allow access to. Views only wants to create vertical and horizontal slices of our collection. What do we mean by a horizontal and vertical slice? Vertical slicing is performed through the use of a project stage. And other similar stages that change shape of the document being returned. Here, we've vertically sliced our document to only retain the accountType field. Vertical slices will change the shape being returned, but not the number of documents being returned. Horizontal slicing is performed through the use of match stages. We select only a subset of documents based on some criteria. Here, we horizontally sliced our collection with the value of the accountType. In fact, the documents that are grayed out would not be operated on at all by the following project stage. We could further slice this data horizontally by only selecting accounts that had a specified minimum balance. And are within a desired age range, and you get the idea. It may even be necessary to use an intermediary shaking stage to calculate a value that we wish to filter documents on. Horizontal slices will affect the number of documents returned, not their shape. Let's look at another example of this with documents that have the following schema. We'd like to vertically slice the documents to remove sensitive information as well as make the name and gender information available. But present it in a more formal format for the call center employees. We'd also like to horizontally slice our collection, by filtering out documents that do not have an accountType of bronze. Here's an example. Creating a view that performs both horizontal and vertical slicing. To make data available for the call center we're going to assign bronze tier members. We specify the name of the view, the source collection, and then the pipeline that will get stored to compute this field. Within the pipeline, we perform our initial horizontal slice with a match stage, selecting only bronze tier members. Then, within the project stage, we perform our vertical slicing. Retaining fields we want and reassigning the name field with a more formally formatted name. You can see this view in action yourself. Let's run the command to get collection information for the current database. Here we see information about every collection. I've already created three views. Bronze_banking, silver_banking and gold_banking. We can see they show up just like collections, except their type is view. And in the options, we can see the view that they are on and the pipeline that defines them. You won't be able to create views on the class atlas cluster. If you'd like to see these views in action and how restrictive they can be along with proper role-based access control, the logging credentials are contained in the handout in this lesson. If you'd like to learn more about role-based access control, refer to our security course which is linked below this video. Views can be created in two different ways. We have the shell helper method db.createView, which we already saw in the createCollection method here. A view consists in a name, a source collection, an aggregation pipeline, and if required, a specific collation. In essence, when we call a view, we will be executing the aggregation pipeline that is used to define the view. View meta information to include the pipeline that computes the view, is stored in the system.views collection. Let's look at this information. Again, we can see the same information we saw before with the get collections info's command, but now only for our views. Hopefully this illustrates that the only information stored by the view is the name, the source collection, the pipeline that defines it, and optionally, the collation. All collection read operations are available as views. And yes, we can perform aggregations on views too. Views do have some restrictions, no write operations. Views are read only and computed when we issue a write operation against them. They are a reflection of the defined aggregation on the source collection. No index operations. Since views use the source collection to get their data, the index operations need to be performed on that source collection. Views will use a source collection's indexes during their creation. No renaming, view names are immutable so they cannot be renamed. That said, we can always drop the view and create it again with the new pipeline without affecting I/O of the server. No $text. The text create operator can only be used in the first stage of an aggregation pipeline. And a view will execute the defined pipeline first, this query operator cannot be used in a viewer. No geoNear or the $geoNear stage. Same as with text, geoNear is required to be the first stage of our pipeline. Collation restrictions. Views have collation restrictions, such as views do not inherit the default collation of the source collection as specified. There are other collation-specific concerns which you can read about by following the link below this video. Lastly, find operations with the following projection operators are not permitted. While moving and retaining fields is allowed, but try to use any of these operators will fail. View definitions are public. Any role that can list collections on a database can see a view definition as we saw earlier. Avoid referring to sensitive information within the defining pipeline. All right, that sums up views. Here are a few things to remember. Views contain no data themselves, they're created on demand and reflect the data in the source collection. Views areread only, write operations to views will error. Views have some restrictions, they must abide by the rules of the aggregation framework and cannot contain find() projection operators. Horizontal slicing is performed with the $match stage, reducing the number of documents that are returned. Vertical slicing is performed with a $project or other shaping stage, modifying individual documents.
