Intro to mongodb relationships
After last article about mongodb fundamentals we had a look at the general data structure but only for one type of collection and the document in that collection. In the real case scenario you might have multiple collections. You might have users, products or orders collections.
So, how we can store related data?
Do you use Embedded Documents or References after reading this tutorial?
Embedded vs References
As I’ve just said, we can have embedded documents or references in a documents.
When you want to use embedded/nested relationship just include one collection in another collection. For example:
Here, my customer has an address which could totally be stored in a new collection. But we can also embedded it into our customer because it’s strongly related to that. You can see embedded relation in black rectangle.
But embedded is not always great approach. Let’s say we still have customers and each customer has a list of his favorite books and we could go with nested or embedded data. So, let’s create array with embedded documents and each document is shortened here:
As you can see if we changed something about that favorite book, we’ll have to change it on all customers. So instead, we need to use references.
We have a customer’s collection and the books collection and in the customer, we still have that array of books but we store there only ID’s. Now if we change the book, we don’t have to change it on 10 different customers but only in the books collection and the ID will never change.
Now you got these two different approaches and now the obvious question is when should you use which?
One To One
In this tutorial I would like to show you first one to one relationship in mongodb. Let’s say we got a couple of drivers and couple of cars. We have the car and this car cannot be owned by a different driver. One driver can drive only one car.
Below is example, how we can create one to one embedded relationship. Let’s say we’re creating our application for a hospital, we got patients and disease summary something like is ill, had previous diseases and list previous diseases.
You could also have one-to-one reference relationships in particular situation. Here is an example. Let’s come back to cars:
As you may see on picture above each driver has one carID related to the car.
You need remember the one-to-one relationship is an extension of one collection by another. So, for many situations with most one-to-one relationships, you’ll probably go with the embedded document.
One To Many
Let’s now have a look at one-to-many relations. For example one blog post has multiple comments, so comment only can have multiple answers. That’s a typical one-to-many relationship. How would you model that in mongoDB?
Many To Many
Now that we had a look at many to many relationship. So let’s say we have customers and products. It’s typical many to many relationship. How could we model that? Use many to many relationships with references. With embedded approach you need to duplicate lots of data. With reference approach you store both id’s in third collection like in SQL databases.
So these are your relation options and I hope my examples gave you feeling how to think about relations and which approach to use. It always depends on your application needs how often you change data etc.
- Group data together logically
- Great for data that belongs together and is not really overlapping with other data
- Avoid super-deep nesting (100+ levels)
- Split your data across collections
- Great related
- Avoid super deep nesting
Now, you know little but more about mongodb!