MongoDB Data Modelling Tutorial With Explanation

MongoDB Data Modelling Tutorial With Explanation from Coding compiler. Let us change our minds and make a more abstract understanding of MongoDB. Introducing some new terms and some new syntax is very easy. It is quite uncommon to accept a model with a new paradigm. Let’s start learning about MongoDB data modelling.

Table of Contents

MongoDB Data Modelling

MongoDB Data Modelling – The truth is that when modelling with new technologies, many of us are still looking for what is available and not available. Here we are just starting a new beginning, and in the end, you need to practice and learn in actual combat.

Document-oriented and relational databases are similar to most NoSQL databases – at least, in modelling. However, the difference is very important.

MongoDB No Joins

The first and most fundamental difference you need to adapt is that MongoDB has no joins. I don’t know the specific reason why links are not supported in MongoDB, but I know that links basically mean they are not extensible. That is, once you extend the data level, you have to give up using the link on the client (application server) anyway. The truth is that data is related, but MongoDB does not support links.

No other way, in order to survive in a connectionless world, we can only implement the link ourselves in our application code. We need to do a second query findto save the relevant data to another collection.

There is no difference between setting up data and declaring a foreign key in relational data. Regardless of our beauty unicorns , let us look at ours employees. First let’s create an employer (I provided a clear one _id so that we can do the same with the example)

db.employees.insert({_id: ObjectId(
    "4d85c7039ab0fd70a117d730"),
    name: 'Leto'})

Then let’s add a few workers and set their managers to Leto:

db.employees.insert({_id: ObjectId(
    "4d85c7039ab0fd70a117d731"),
    name: 'Duncan',
    manager: ObjectId(
    "4d85c7039ab0fd70a117d730")});
db.employees.insert({_id: ObjectId(
    "4d85c7039ab0fd70a117d732"),
    name: 'Moneo',
    manager: ObjectId(
    "4d85c7039ab0fd70a117d730")});

(It is necessary to repeat it again, it _id can be a unique value in any form. Because you are likely to use it in practice ObjectId , we are also using it here.)

Of course, to find out all the workers of Leto, you only need to perform:

db.employees.find({manager: ObjectId(
    "4d85c7039ab0fd70a117d730")})

This is nothing magical. In the worst case, most of the time, to make up for no link is just to add an extra query (which may be indexed).

MongoDB Arrays and Inline Documents

MongoDB doesn’t support links, it doesn’t mean it has no advantage. Remember when we said that MongoDB supports arrays as basic objects in documents? This is very convenient when dealing with many-to-one or many-to-many relationships. For a simple example, if a worker has two managers, we only need to save the array like this:

db.employees.insert({_id: ObjectId(
    "4d85c7039ab0fd70a117d733"),
    name: 'Siona',
    manager: [ObjectId(
    "4d85c7039ab0fd70a117d730"),
    ObjectId(
    "4d85c7039ab0fd70a117d732")] })

Interestingly, for some documents, it manager can be a single, different value, while others can be arrays. And our original find query is still available:

db.employees.find({manager: ObjectId(
    "4d85c7039ab0fd70a117d730")})

You’ll quickly discover that values in arrays are much easier to handle than many-to-many join-tables.

In addition to arrays, MongoDB also supports inline documents. Try to insert an inline document into your document, like this:

db.employees.insert({_id: ObjectId(
    "4d85c7039ab0fd70a117d734"),
    name: 'Ghanima',
    family: {mother: 'Chani',
        father: 'Paul',
        brother: ObjectId(
    "4d85c7039ab0fd70a117d730")}})

As you can guess, inline documents can be queried with dot-notation:

db.employees.find({
    'family.mother': 'Chani'})

We will simply cover the application of embedded documents and how you can use them.

Combining two concepts, we can even embed a document array:

db.employees.insert({_id: ObjectId(
    "4d85c7039ab0fd70a117d735"),
    name: 'Chani',
    family: [ {relation:'mother',name: 'Chani'},
        {relation:'father',name: 'Paul'},
        {relation:'brother', name: 'Duncan'}]})

MongoDB Denormalization

Another alternative to linking is to denormalize your data. Historically, denormalization is designed to address performance-sensitive issues or data that needs to be snapshotted (such as audit logs).

However, with the growing popularity of NoSQL, the increasing loss of support for links, anti-normalization is becoming more and more common as part of standardized modeling.

This does not mean that every piece of data in your document should be redundant. Rather, rather than fearing redundant data and letting it influence your design decisions, it’s better to consider what information should belong to the document when modeling.

For example, suppose you want to write a forum application. Conventional manner through posts the userid column, to associate a particular user and one post. With this kind of modelling, you ca posts n’t query (link to) when it’s displayed users.

Instead of a simple case of each of post the put name and userid saved. You may want to use inline documents, for example user: {id: ObjectId('Something'), name: 'Leto'}. Yes, if you let users update their names, you have to update all the documents (a multiple update).

Adapting to this method is not as simple as anyone. In many cases, this is even meaningless. But don’t be afraid to try. It is only not applicable in some cases, but in some cases it is the best solution.

What is your choice?

The id array is usually the right choice when dealing with one-to-many or many-to-many scenarios. But often, newcomers are struggling with inline documents and “manual” references.

First of all, you should know that the size of a standalone document is currently limited to 16MB. Knowing the size limit of the document, it is quite generous, and it has some influence on how you think about it.

At this point, it seems that most developers are willing to manually maintain data reference relationships. Inline documents are often used, in most cases, very small blocks of data, those that are always pulled with the parent node. A realistic example is to save one for each user addresses , which looks like this:

db.users.insert({name: 'leto',
    email: '[email protected]',
    addresses: [{street: "229 W. 43rd St",
                city: "New York", state:"NY",zip:"10036"},
               {street: "555 University",
                city: "Palo Alto", state:"CA",zip:"94107"}]})

This doesn’t mean you have to underestimate the ability to embed documents, or just use them as tips. Mapping your data model directly to your objects makes the problem simpler and usually does not require links. In particular, the effect is especially noticeable when you consider that MongoDB allows you to query and index fields in embedded documents and arrays.

MongoDB Specialized Collection

Since there is no mandatory requirement for the collection, it is perfectly possible to use a collection of various documents in the system, but this is definitely a very bad idea. Most MongoDB systems use a similar structure to a relational database, divided into several collections. In other words, if there is a table in the relational database, then it will be created as a set in the MongoDB (many-to-many join tables is an important exception as well as tables that exist only to enable one to many relationships with Simple entities).

This topic becomes more interesting when you take in embedded documentation. A common example is a blog. Should you split into a posts collection and a comments collection, or should post you embed an comments array below each ? Regardless of the 16MB document size limit (_Hamlet_full text is no more than 200KB, so how popular is your blog?), many developers like to divide things.

This is more concise and clear, giving you better performance. MongoDB’s flexible architecture allows you to combine these two methods. You can put comments in a separate collection and embed a small number of comments (such as the latest comments) under the blog post to display with the post. This follows the rules below, which is what you want to get in a query.

There is no hard and fast rule (well, except for the 16MB limit). Try to solve the problem in different ways, you will know what can be used and what can not be used.

Summary

The goal of this chapter is to provide some guidance on how to help you model data in MongoDB, a new starting point, and you can think of it if you like. Modelling in a document-oriented system is not the same as modelling in a relation-oriented world, but it is not much different. You get more flexibility and only one constraint, and for the new system, everything is perfect. The only thing you can do wrong is that you don’t try.