MongoDB CREATE VIEW (14)

National day to enlarge the false, conveniently turned over the English vocabulary problem, see idea, opinion, View and thought four options, suddenly think of the new features of MongoDB read-only View, so on the way to promote a bit.

Remember MongoDB World announced that the next version of MongoDB 3.4 will bring a lot of new features for the immediate bright, the first one is view, so during the national Day holiday, we will sneak peek!

Out

The word view is not a stranger to professionals, and translation is "view". In the previous version of MongoDB, if you want to construct a subset of a collection, personal understanding should have two ways, one is to recreate a collection, redundant, or very convenient. The performance of this method is largely unaffected, but if the data is dynamically changing, synchronization can be a little cumbersome. The other is the direct fencing with the MongoDB aggregation framework to complete, but to be honest, too many brackets, curly braces, sometimes look too tired.

So the view vacated the birth is not accidental, and is definitely open "big Yang line" time!

In the MONGO view, there is no real data, it can be simply regarded as a "pseudo-set." When you need to access the contents of a view, the view data is aggregated from the source collection in real time. Obviously, there is no space occupancy problem, which is much stronger than redundancy. Of course, there is a small exception, that is, the System.views collection, which contains all the definition of the view of the content, fortunately, not much space.

Build

The creation of the view is very simple, Db.createview followed three parameters, the first is the view name, the second is the source set name, and the third is the aggregation condition. So we can create a view that contains all the data for the state "AL":

Then directly through the DB. State_al the query operation and enumerates the first 3 data.

Operation

What can you do with the creation of a view?
Once the view is created, you can make any query operation on the views, the action content is exactly the same as the standard query operation, and you can proceed with the aggregation framework operation. But remember, this is a read-only view and cannot be written! Of course, there are some small restrictions, such as the inability to use MapReduce, can not use $text for full-text search and so on.
For example, the above State_al view is aggregated again, showing only the city and Zip fields:

Scene

In fact, the most valuable part of the product is not the function, but is not useful, this is the place to settle down. So let's see where the MongoDB view can be used. That's the key!

Scenario One: Extended security
We know that MongoDB security as a whole compared to other non-relational databases, the overall still doing well, especially in the enterprise version of the enhanced CRUD upgrade, encryption engine and so on. But security and convenience are basically never going to go together, so configuring security based on the role of field-level control or the need for some brain cells.
Can you make it easier to be safe?
In fact, a view is a good way to do it. Let's say you have a data collection that contains all the data, but I don't want all the data to be open to developers, such as credit card fields, ID numbers, and so on, so you can't create a new view with a filter, and the problem is solved.
So simply, isolating read-only access is a good view case.

Scenario Two: Simplifying logic
MongoDB's aggregation framework is really good, and more and more of the $ function is added to the aggregation framework, so long filter conditions are quite time-consuming to write. However, with view, those frequently used filter aggregations can be cured, then the query for the subset will become simpler, the application logic can be simplified.
For example, assuming that the application system requires that each state can only check local zip code, then the ZIP data in the $match to match the data of a certain state can be very convenient to split the data, and then continue to be applied access.

Reef

Read-only views are really good, but important things need to be said three times, read-only, read-only, or read-only. The attempt to write can only accept failure, of course:

There are several other points to note:
1. Dynamic changes
* View data changes dynamically as the source collection data changes, because the view itself does not hold data, but is calculated in real time to the source data collection.
* When the source data collection is deleted, the view naturally gets no data and returns NULL.
* And when the source data is deleted and restored, the view can recover the data completely.
2. Parasitic efficiency
* Views do not improve query efficiency, the query efficiency depends entirely on the index in the source data collection, so the view itself does not have the power to determine efficiency.
3. Iterative multiplexing
* Views can be built on an existing view, so it's easy to iterate.

***************************************************************************************************************

Exercise 1: Create a View and sort

Db.createview ("View_attenddata", "Attenddata", [{$match: {"sheetID": "5949f0277d6156d5d4c5740d"}},{$sort: {" Data.date ":-1}}])

Exercise 2: Create a view and sort, and then select a field

Db.createview ("View_attenddata", "Attenddata", [{$match: {"sheetID": "5949f0277d6156d5d4c5740d"}},{$project: {" Data.date ": 1," _id ": 0}}, {$sort: {" Data.date ":-1}}])

MongoDB CREATE VIEW (14)