Comment choisir entre SQL et NoSQL ?

Pour commencer, les choix de technologies pour un projet doivent toujours découler de la phase d'analyse et de conception, et non l'inverse. Peu importe si une technologie est à la mode ou non, la question principale doit-être :

"Est-ce que cette technologie va me permettre de créer un logiciel robuste, efficace, durable et maintenable dans le temps.

C'est exactement cette réflexion que vous devez avoir pour choisir votre base de données, et la première étape est donc de réfléchir au domaine métier du projet, grâce à un modèle conceptuel de données (aussi appelé MCD).

Par exemple représenté sous la forme d'un schéma appelé "modèle entité-association", l'objectif va être de lister les entités dont va dépendre notre futur logiciel ainsi que les relations logiques entre ces dernières. Exemple :

Cette représentation permet de cadrer/spécifier techniquement les données du projet sans avoir à parler d'une quelconque technologie. Et c'est notamment ces spécifications qui vont nous permettre de décider (entre-autres) le ou les modèles de bases de données que nous allons devoir utiliser.

Relationnel vs Non-relationnel

Je tiens à préciser que le titre de l'article parle de "SQL" et "NoSQL", mais en réalité on va plutôt parler de modèle "relationnel" et "non-relationnel"

Relationnel

Comme son nom l'indique, le fondement du modèle relationnel réside dans les associations fortes entre les entités, ce qui signifie que notre modèle de données n'est complet que lorsque les entités de ce dernier sont robustes, vérifiées et vérifiables.

Prenons par exemple un site e-commerce ultra-simpliste qui n'aurait que deux entités: des utilisateurs et des produits.

En ayant une liste de tous les utilisateurs et de tous les produits disponibles, nous aurions suffisamment de données pour afficher la première page du site, mais en réalité notre logiciel ne serait qu'une coquille vide.

Ce sont les relations entre ces deux entités qui vont faire toute la logique de notre système : chaque objet est vendu par un utilisateur spécifique, et chaque commande est simplement une relation entre un utilisateur (l'acheteur) et un produit.

Ici les relations ont tout autant (voir plus) de sens que les données en elles-mêmes ! C'est donc un modèle relationnel.

Oui mais...

Si l'on part de ce principe-là, quasiment tous les logiciels ont des entités qui sont en relations les unes avec les autres, ça voudrait dire que dans 95% du temps nous aurions besoin d'un système de gestion de base de données relationnel ?

Bingo, c'est exactement ça. Et la possibilité de s'assurer de la cohérence des données et des relations à tout moment est l'avantage principal de ces systèmes, qui vous permettent en réalité de pouvoir dormir sur vos deux oreilles.

Et si les performances des modèles relationnels vous fait peur, rappelez-vous que Facebook utilise MySQL comme base de données principale, cela devrait vous rassurer !

Non-relationnel

Ces dernières années, les systèmes de gestion de bases de données non-relationnelles ont eu le vent en poupe, notamment autour des sujets du passage à l'échelle, des systèmes distribués et du cloud.

Cette popularité croissante a joué un rôle important sur la manière dont les nouveaux développeurs et développeuses abordent désormais le sujet des bases de données.

L'apparente simplicité d'utilisation et la flexibilité du stockage de données non-structurées ont poussé beaucoup de développeurs à remplacer leurs bases relationnelles (SQL) par du NoSQL.

Si ce remplacement fonctionne en théorie et peut simplifier les choses sur de petits projets, cela revient en réalité à couper la branche sur laquelle on se trouve, car on se prive alors (au moins en partie) des concepts de cohérence et de durabilité des données.

Pour répondre à la question initiale, voici quelques cas d'usage où l'on va pouvoir privilégier les bases de données NoSQL :

• Le temps-réel
• Le big-data
• La gestion de cache (pages, requêtes,...)
• La gestion des sessions utilisateurs
• ...

Il est bon de noter qu'en général dans un projet, une base NoSQL ne vient pas remplacer une base de données relationnelle mais vient plutôt en complément de cette dernière !

Si vous voulez découvrir un exemple de SGBD NoSQL avec la présentation de quelques cas d'usages, je vous invite à lire mon article d'introduction à Redis.

Conclusion

Si l'on devait résumer, toutes les entités présentes dans votre modèle conceptuel de données qui sont reliées à d'autres entités par une association logique et dont la valeur dépend de cette relation doivent être stockées dans une base de données relationnelles (entendez SQL).

Pour les autres données de votre modèle du domaine (si vous en avez) qui sont indépendantes les unes des autres, où bien celles liées à des contraintes techniques (stockage de session, cache, etc...), alors il ne vous restera plus qu'à déterminer quel SGBD non-relationnel correspond le plus à vos besoins !