Database Design in MongoDB
You have finally decided on a project idea, and are all set to take the world by storm by coding the most amazing application. You understand your data well, but, lo and behold, your application is performing at a very slow speed. Now that will not take the world by storm, perhaps not even by a breeze! You look into what brought about that situation and find that it was all due to the poor database design.
Database design is the process of organizing data according to a database model. We will be focusing on the NoSQL database design; MongoDB in particular. If you are new to the NoSQL type of database, you can check this article out. When we start designing a database, our first instinct is to design schemas like relational databases, and rightly so, because neat little tables are way easier to understand than somewhat complex JSON objects. Let us see both of those types in action to understand it better.
In relational schema design,
We have the Employees table and Branches table with a little information on both of them. We form a new table using those tables. Normalization should always be considered in relational schema design.
According to our data, Jim Halpert transferred from Scranton to Stamford in 2007. We can model the same information in MongoDB schema design as
MongoDB Schema design provides us with a lot more freedom than relational schema design. There are no rules, formal processes or algorithms to consider in this kind of design. But, the most important thing is that you need to Know Your Application!
In Relational Schema design, you can start modelling data independent of queries, but you need to consider query performance while modelling in MongoDB. You need to consider how to store our data and our hardware requirements as well.
MongoDB schema design can be done using either Embedding or Referencing.
Embedding
When we have all the related data in a single document, we call it embedding. This data model is also called a de-normalized data model. The example that we saw just above was an embedded data model or embedding style of design. As we can guess for ourselves, its advantage is that we can retrieve all the data with a single query, and it avoids the expenses of the JOINs. Its disadvantage is the overhead for large documents. In order to overcome that, we use referencing.
Referencing
Referencing is another option of designing our schema where we can refer to the sub-documents in the original document, using references. It is analogous to JOIN operators in an SQL query.
Now that we have some idea about referencing and embedding, let us move on to the types of modelling relationships used in MongoDB. We will be discussing only the simple ones right now, but if you want to learn more, the internet is your playground! Go for it!
One-to-one
It is the simplest kind of relationship with key-value pair embedded in the document.
One-to-Few
If we are dealing with a small sequence of data associated with our given model, we use a one-to-few relationship. It is the same as one-to-one, just with an additional embedding.
Here, Jim Halpert worked for more than one branch, so we can have a one-to-few relationship.
One-to-Many
We might encounter a situation when our model needs to link with several different documents for complete information. That is the situation of a one-to-many kind of relationship.
In the above example, Jim Halpert receives a number of reviews and has a one-to-many relationship. We can notice that I have used referencing method of schema design in this case.
Similarly, there is one-to-squillion for the cases where there could be millions of sub-documents and many to many where many tasks may be assigned to many users.
These are some of the things to consider while designing a database in MongoDB, but I repeat, know your application first. After you know your requirements, then it will be much easier to know what you are supposed to use, and you can maximize your performance.