MongoDB or Mysql? NoSQL or Rational SQL? which is better for me?

MongoDB or Mysql? NoSQL or Rational SQL? which is better for me?
In this post I will quickly present each database type, and tell you how you should decide which database to implement on your next project.

MySQL is a rational type of database, used and loved by many. It’s usually used with PHP as part of the LAMP package (Linux, Apache, Mysql, PHP). MySQL powers many PHP-based websites and web apps, including: WordPress, Drupal and more. MySQL is based on tables and rows which are normalized using references/index/keys between them. This aims to save disk space on the server, keep data consistence and more.

MongoDB is a NoSQL type of database, “younger” compared to MySQL. It’s based on Documents and Collections. MongoDB is meant for building complex distributed systems, with emphasis on horizontal scalability. It’s usually used as part of the MEAN package (MongoDB, Express, Angular, Node.JS).

So, How should you decide?

When starting to plan and work on your next project, part of your troubles are related to database selection.
Deciding which database to go with can be hard: “I already know how to work with…”, “I think this DB would be better…”, “it would be easier and faster for me to implement this db” and such self-convincing phrases.

But, the solution is “simple”!
When you need to decide on a database for your project, ask yourself these questions:

• Will I need to duplicate critical data?
• Will I need to reference/link between tables, use Joins?
• will I need the data to be consistent?

I’m referring to this as “simple” because it is not that simple at all.
You would need to understand your project’s system, investigate the data it will hold and the different queries it would run.
Then you can know what is the critical data for your system, how it will be accessed, how it will be changed etc.
Also you would have a better understanding of the types of data structures your system would handle, and the needs for linking and referencing between them.

For example:

• Social network’s data (social data) should be access quickly and rapidly. We care less about consistency. And so, MongoDB would be more suitable.
• Payments and transactions data is sensitive information which has reference to other entities in your system, and, more importantly, needs to be consistent, without any duplicates in the system. And so, MySQL would be more suitable in this case.

Remember:

1. Document (in MongoDB) is like a stand-alone data structure.
2. It may have sub structures and pieces of semi-structured data. But they are all contained within the Document.
3. The document has its own internal structure, but it doesn’t link to other documents.

More importantly:

1. MongoDB offers Schema flexibility, which may sound like a great idea, but it’s useful when the structure of your data has no value to your business. If your data has meaning, and it used to drive business logic and needs — then MongoDB is the wrong choice.
2. The business value lies in your data, and it’s important to understand where in your data and its connections this Business Value is found.
3. Do not choose a data store that would put your into a corner.
4. Easily adding the features your business needs — that is where the true flexibility of the database lies.

Hope this helps you for your next big project