Skip to main content

Data relationships in Mongo DB

There is an ongoing and passionate discussion of “Relational vs. NoSQL” databases. The comparison is not very well understood and in my opinion makes little sense and here is why.

The “Relational Database” world is very well defined and most of the products share a large, if not complete, set of features. On the other hand, the so called NoSQL world, by definition covers that which falls outside of the Relational.

To make an analogy, the comparison is equal to saying: “Let’s compare four door family sedans with everything that drives and is not a four door family sedan.”. That would include transport trucks, cars, electric mopeds and perhaps riding lawn mowers. Just like the NoSQL world would include things that vary from key value pair storage to … well, whatever you can think of.

To deal with the ridiculousness, I urge you to take a much more sane comparison. MongoDB vs Relational Database. In particular, I invite you to examine the “relational” aspect.

Relational Model vs Relationships

Relational Model organizes data into multiple tables and rows each having a unique key. The keys are used to create relationships between records in tables. It sounds obvious, but let’s look at it deeper. The Model is needed to store the data in a way that preserves relationships between data. The “relationships” between the data is the ultimate necessity here. This sound quite academic and perhaps is better looked at in a practical example.

Order information is something dear to us all. Let’s use that as a practical example to demonstrate what is being said here.

To simplify the concept let us imagine a very basic invoice. It contains: buyer name, billing address, shipping address, items and the total.

In a relational database we would need to create several tables and tie them together with keys. A simple example would have us create a table that hold customer information. Assuming that the billing address may differ from that information we will create a table dedicated to billing addresses, one per order. We will do the same for the shipping address since not everything is always shipped to the same address. Finally we will create a table to hold order items, their quantities and prices. Our database schema would end up looking something like this.

I have only showed they keys columns as the rest of the information is not important at this time.

As you can see a very basic order creates a fairly complex relationship of 5 tables. Once an order comes in the data needs to be disassembled into appropriate chunks, stored in appropriate tables and the keys need to be generated and used. All this is done for one reason – maintaining relationships between newly generated parts of data.

Now let’s look at how the same data can be stored in the MongoDB, which uses JSON as a storage format.

First thing to notice that there is only one “id” created – order id. No keys are created to tie the rest of the data together. All the data simply exists inside a single document. What does this mean?

No “relational model” needs to be used to store the data, yet relationships are still maintained.

This is the main point of MongoDB vs Relational Database discussion. This is the primary difference.

Are there limitations when working with MongoDB? Of course.

Are there things that MongoDB can do that “relational” database can not? Of course.

Now you are ready to start looking at things in an informed way. More on that latter.

Share this story

Arctiq Team

We service innovation.