Understanding How Document Databases Work
Data is the backbone of most applications, especially for web and mobile apps. Without data, you can’t retrieve information, have users login, or build out much of anything. The way that most data is stored for web & mobile apps is through some kind of database. I’m sure most of you know how simple databases work, but let me illustrate with an example from a simple relationship database perspective.
Let’s say I have two sets of data and I want to relate them together: a data set of users and a data set of posts. In a normal relational database (like MySQL for example), I would have each set of data in a different table.
I would then have to link the two tables or “relate” them together. This is done by having a primary and secondary key (or foreign key). For this simple example, I would link the Posts “user_id” field to the Users “_id” field. This would create a relational link for me to retrieve data between them.
Ok, now let me show you how this would work if I’m using a Document Database (also known as NOSQL) with MongoDB.
The first thing, I need to keep in mind is data is not stored in tables, but rather in objects. That’s great for us, especially if we’re using JavaScript, as objects are really easy for us to manipulate on the front end of our applications.
So, if this was an object MongoDB database, I would have two different “tables” or in this case Collections
For MongoDB “Tables” are called Collections and “Records” are called Documents.
One Collection for Users:
&
One Collection for Posts:
Now, what do I do if I want to retrieve a collection of posts from a single user (the “documents” that I want)?
There are a couple of ways I could do that:
Embed one collection inside the other
This is a viable way to do it, particularly if you have one-to-one or one-to-many relationships, as is the case with posts. In this case, you would have the posts nested inside of the user collection as an array of objects.
Provide a “relation” between them
Although the above method is valid, if I had a many-to-many relationship I would probably not use this way. For example, if I want to have a post that is posted by a single person, but can have other people like it and share it, it would be a lot easier for me to conceptualize and map out those other actions that a user could perform, if I store data as a separate collection, and “relate”them together.
Wait, you might say. I thought that Document Databases don’t allow you to “relate” data together?
While it’s true that you can’t have a primary / foreign key relationship, you can still mimic having a “relationship” by inserting a primary key into the collection you want to relate to.
In our example, that would mean that:
1) We would have to insert a reference to the Posts collection, inside of the Users collection, for us to know who posted a certain post.
2) We would have to insert references to the Users collection into the Posts collection, for us to know who “liked” or “shared” a certain post.
The result would give us the following (for NodeJS applications, the below can be accomplished using Mongoose):
Based on what I’ve seen, this is the best way to do it if you have 2 large collections that you want to relate together, especially if they have a complicated relationship between each other (which could be many-to-many).
I hope this was beneficial to you on your journey to learn about databases and application backends!
I help run the first and premium Dubai Coding Bootcamp on Web Development, where we go in detail not only in MongoDB, but also Node JS, React and everything a modern web developer needs to know!
