Can a document based database be relational?

This is an answer to the question in the title (question) asked by Dan from the Insider Club. I post it here so it does not get lots in the depths of the forums…

Hey Dan,

your question touches on a topic dear to my heart. Many people use the word “relational database” in a vague and incorrect way… This breeds confusion in their minds and this is not great at all!

So can a document based database be relaitonal?
Short answer is “yes”.

A bit longer answer: Document databases can be as relational as MySQL. However it’s mostly your app what makes the relations. This is not to be feared because you are currently doing the same with MySQL.

Further explanation.

But first let me state something that is not obvious for many many people out there. And because you are asking the question I assume you are in that group too!

The way people use MySQL out there is not relational in a way.
JOINS are not what makes MySQL, PostgreSQL or other databases “relational”. You can do a “join” procedure with pretty much any database out there. And that includes document based databases and graph databases like neo4j.

You can certainly store connected data in Mongo

What Actually makes MySQL a relational database are things that pretty much nobody is using these days. When I say pretty much I mean 95% of the websites out there are not making use of any of these things.

The whole difference is not what you can do with a database. It’s how the creators think about data.

MySQL was created by people who probably thought

  • it would run on a single or at most several servers at once, for most sites this is still true but not so with the cloud apps.
  • all the data within the db it will be interconnected and the relations will be described in the database (trough use of things like “FOREIGN KEY” commands and “ON DELETE CASCADE” definitions when creating/altering tables – today connections are described in the application’s models through joins. Nobody puts their model descriptions in the database.

In the old days there was a war of relational databases, just like it is now between Document and Relational DBs. Every company wanted to make their DB more “relational” and they kept stacking features that allowed you to do everything in the database. So much that you can now write a interpreters for other languages in SQL. Meaning SQL is a complete programming language 🙂

Enough on the side note.

Mongodb is not relational because it is not meant to do many of the things MySQL does do.
MongoDB thinks of units of data in a very similar way to documents. However this is very very very similar to MySQL and has differences too.

Basic dictionary for MongoDB newcomers:

Collection – Table
Document – Row
Field – Column
Index – Index
Aggregation – Joining

Basic differences in Mongo:
* it is “soft” you do not define type of data for your fields (“columns”), however for sanity you probably will define field data types in your models.
* is fast and distributed – can work on a ton of servers at the same time and is faster for many operations that MySQL has problems with.

In conclusion I want to say that pretty much any database out there can do pretty much everything. So choice does not depend so much on what can be done with that DB.