MongoDB Data Modelling Tutorial With Explanation

MongoDB Data Modelling Tutorial With Explanation from Coding compilerLet 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.

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.

Related MongoDB Tutorials

What is MongoDB Tutorial For Beginners

MongoDB Basics Tutorial

MongoDB Update Tutorial

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(
    name: 'Leto'})

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

db.employees.insert({_id: ObjectId(
    name: 'Duncan',
    manager: ObjectId(
db.employees.insert({_id: ObjectId(
    name: 'Moneo',
    manager: ObjectId(

(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(

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(
    name: 'Siona',
    manager: [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(

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(
    name: 'Ghanima',
    family: {mother: 'Chani',
        father: 'Paul',
        brother: ObjectId(

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

    '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(
    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.


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.

Related MongoDB Tutorials For Beginners

What is MongoDB Tutorial For Beginners

MongoDB Basics Tutorial

MongoDB Update Tutorial

MongoDB Query Tutorial

Leave a Comment