After 6 years of practicing MongoDB, Here are my thoughts on MongoDB vs MySQL

Introduction

Let's first start with a brief introduction to MongoDB and MySQL.

MongoDB is a document-oriented NoSQL database. It is a cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas. MongoDB is developed by MongoDB Inc. and licensed under the Server Side Public License.

MySQL is a relational database management system (RDBMS). It is a cross-platform database management system. It is a relational database management system based on SQL (Structured Query Language). MySQL is developed by MySQL AB and is now owned by Oracle Corporation.

Working with MongoDB

TBH, initially i was so excited to begin working with, due to its extreme flexibility and the ability to store documents (rows) in one collection instead of mapping it into multiple tables, that was really attractive feature to me.

However, when starting working on real projects with larger data, things didn't go very smoothly to me, tables became too big and it was hard to maintain them, and the performance was not as good as i expected.

But having a flexible schema made me continue using it, it was really very useful specially the projects i started working on it has more dynamic data per table (collection), no need to create table, nor columns, just insert the data and you are good to go.

The downside of MongoDB

The downside of MongoDB is that it is not a relational database, so you can't join tables (collections) together, and you can't use SQL queries, you have to use MongoDB queries, which is not that easy to learn, and it is not that easy to use.

Also you've to keep your eyes on the data that are being duplicated everywhere in your database, for example, if you're working with a posts table which includes the author and the post category, the trick here you can inject the author data and the category data into the post document, but you have to keep in mind that if you update the author or the category, you have to update the post document as well, and this where issues will begin to populate if you forget to run a query to make this update.

The upside of MongoDB

On the other hand, as mentioned earlier, working with a flexible schema per table (collection) was really nice and useful.

Also, the performance was really good, and the querying was really fast, and the indexing was really fast as well, but this needs more practice to know when you should store documents inside other documents and where just leave a reference id.

Tough Control is what you need

To put it in a nutshell, all you need is to make a very good control of your data, and start mapping and make relations between your tables (collections) in your code, this will of course make you write more queries for insertions, updates and deletes but the fetching is really really good as you don't need to make multiple queries most of the time.

What i did to make a good control over MongoDB

Events where my master key here, i used events to make sure that when i update a post i also update the author and the category as well, for example i add an event in the Category Model class, that when it is updated, make an update in the post table in a certain column category column.

And i ended up with these situations:

• 1-1: Here whereas a one document is inserted in another document, for example one post has one category.
  • Update: category is inserted into post, so when category is updated, find all posts that have that category id and update it.
  • Unset: category is inserted into post, so when category is deleted, find all posts that have that category id and unset the category data, which means the post will be left without a category.
  • Delete: category is inserted into post, so when category is deleted, find all posts that have that category id and delete all posts have this category id.
• 1-n: here whereas a one document is inserted in multiple (embedded) documents in another document/collection, for example one post has multiple comments.
  • Update: comments are inserted into post, so when comment is updated, find the post that have that comment id and update it, which will be stored in an array of comments.
  • Unset: comments are inserted into post, so when comment is deleted, find the post that have that comment id and pull it from the array, which will be stored in an array of comments.

There are more situations, but these are the most common ones.

Conclusion

This article is not a comparison about MongoDB and MYSQL or NoSQL and MYSQL databases, i'm just sharing my thoughts about the two databases structures.

I do really like MongoDB, if you want to really enjoy it and use it properly, don't try to SQL it, it has a different approach so you need to learn how it works, and how to make a good control over your data.

I'm still working with MongoDB, no plans to change it later until i find a better solution.

I hope you enjoyed this article, and if you have any questions, feel free to ask me in the comments section.