## How to choose between SQL and NoSQL?

To begin with, technology choices for a project should always stem from the analysis and design phase, not the other way around. It doesn't matter whether a technology is trendy or not, the main question should be:

"Will this technology allow me to build software that is robust, efficient, durable, and maintainable over time?"

This is exactly the kind of thinking you need to have when choosing your database, and the first step is therefore to think about the business domain of the project, using a conceptual data model (also known as CDM).

For example, represented as a diagram called an "entity-relationship model," the goal is to list the entities that our future software will depend on, as well as the logical relationships between them. Example:

This representation allows us to technically frame/specify the project's data without having to talk about any particular technology. And it is precisely these specifications that will allow us to decide (among other things) which database model(s) we will need to use.

Relational vs Non-relational

I want to clarify that the title of the article mentions "SQL" and "NoSQL," but in reality we should rather talk about "relational" and "non-relational" models.

Relational

As its name suggests, the foundation of the relational model lies in strong associations between entities, which means that our data model is only complete when the entities within it are robust, verified, and verifiable.

Let's take, for example, an ultra-simplistic e-commerce site that only has two entities: users and products.

By having a list of all users and all available products, we would have enough data to display the homepage of the site, but in reality our software would just be an empty shell.

It's the relationships between these two entities that make up all the logic of our system: each item is sold by a specific user, and each order is simply a relationship between a user (the buyer) and a product.

Here, the relationships have just as much (if not more) meaning than the data itself! So this is a relational model.

Yes, but...

If we go by this principle, almost all software has entities that are related to one another, wouldn't that mean that 95% of the time we would need a relational database management system?

Bingo, that's exactly it. And the ability to ensure the consistency of data and relationships at all times is the main advantage of these systems, which really allow you to sleep soundly.

And if the performance of relational models worries you, remember that Facebook uses MySQL as its main database, that should reassure you!

Non-relational

In recent years, non-relational database management systems have gained a lot of traction, particularly around the topics of scalability, distributed systems, and the cloud.

This growing popularity has played a significant role in how new developers now approach the subject of databases.

The apparent ease of use and the flexibility of storing unstructured data have pushed many developers to replace their relational (SQL) databases with NoSQL.

While this replacement works in theory and can simplify things on small projects, it actually amounts to cutting off the branch you're sitting on, because you then give up (at least partially) the concepts of data consistency and durability.

To answer the initial question, here are some use cases where NoSQL databases may be preferable:

• Real-time processing
• Big data
• Cache management (pages, queries, etc.)
• User session management
• ...

It's worth noting that generally, in a project, a NoSQL database doesn't replace a relational database but rather complements it!

If you'd like to discover an example of a NoSQL DBMS along with some use cases, I invite you to read my introductory article on Redis.

Conclusion

To sum up, all the entities present in your conceptual data model that are linked to other entities through a logical association and whose value depends on that relationship should be stored in a relational database (i.e., SQL).

For the other data in your domain model (if you have any) that is independent of one another, or that is related to technical constraints (session storage, caching, etc.), all that remains is to determine which non-relational DBMS best fits your needs!