
Code-Garage #92 - SQL vs NoSQL
Durée: 8m52s
Date de sortie: 29/02/2024
Beaucoup de devs hésitent entre les bases SQL et NoSQL pour le projet, mais nous allons voir ensemble que le choix est très simple à faire quand on se pose les bonnes questions !
Notes de l'épisode :
- Article d'origine : https://code-garage.fr/blog/comment-choisir-entre-sql-et-nosql/
- Introduction à Redis : https://code-garage.fr/redis-une-base-de-donnees-rapide-comme-l-eclair/
Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Brandin-Bernard et aujourd'hui on va parler de la différence et des choix qu'on
peut faire entre une base SQL et une base noSQL. Alors pour commencer, les choix des technologies
pour un projet doivent toujours découler de la phase d'analyse et de conception du projet,
et non l'inverse. Peu importe si une technologie est à la mode bas, la question principale,
ça doit être, est-ce que cette technologie va me permettre de créer un logiciel robuste,
efficace, durable et maintenable dans le temps. Et c'est exactement cette réflexion que vous
devez avoir pour choisir votre base de données. Et la première étape, c'est donc de réfléchir
au domaine métier du projet. Alors ça peut être avec un modèle conceptuel de données,
un MCD, ça peut être d'autres méthodes, mais moi je vais prendre celle-là parce que c'est
un projet vraiment fictif de gestion, d'école, de calendrier, d'élèves, de professeurs, etc.
Eh bien on va faire un schéma qui va lister les entités dont va dépendre notre futur logiciel et
les relations logiques entre ces entités. Donc par exemple on va avoir des étudiants, des professeurs,
des salles de classe, des bâtiments, des adresses, des horaires, des cours, des thèmes, etc. Et
tout ça, il va y avoir des relations logiques entre les deux puisque un professeur va donner
un cours dans une salle de classe et cette salle de classe va être remplie d'étudiants qui vont
assister à ce cours, etc. Cette représentation, ça permet de cadrer ou de spécifier techniquement
les données du projet sans avoir à parler d'une quelconque technologie. Et c'est notamment
cette specification qui va nous permettre de décider, alors entre autres, il peut y avoir
d'autres spécifications autour du projet, les systèmes plutôt de gestion de base de données
qu'on va devoir ou pouvoir utiliser. Alors là on va faire un sceau qui est hyper important,
c'est on va essayer d'arrêter de parler de SQL et de NoSQL, mais on va plutôt parler de
modèles relationnels versus non relationnels. Alors le relationnel comme son nom l'indique,
c'est le fondement de ce modèle, ça réside dans des associations fortes entre les entités,
ça signifie que notre modèle de données que lorsque toutes ces entités et ces associations
sont robustes, vérifiées et vérifiables. On a pris tout à l'heure l'exemple de la
gestion salle de classe, ça pourrait être la même chose pour un city commerce, même s'il
est ultra simpliste, des utilisateurs des produits et des paniers pour acheter, en ayant une liste
de tous les utilisateurs et de tous les produits disponibles, on aurait suffisamment de données
pour afficher la première page du site, mais le reste du logiciel, ça serait qu'une
coquille vide, c'est les relations entre les entités, donc les produits et les utilisateurs,
qui vont faire toute la logique de notre système, chaque objet vendu par un utilisateur spécifique
et chaque commande est simplement une relation entre un utilisateur, l'acheteur et un produit.
Donc ici les relations, elles ont tout autant voire plus de sens que les données en elles-mêmes,
c'est donc ce qu'on va appeler un modèle relationnel. Oui mais alors c'est vrai que si on part de ce
principe là, quasiment tous les logiciels ont des entités qui sont en relation les unes avec les
autres, ça veut dire que ça voudrait dire en tout cas que 95% du temps, on aurait besoin d'un
système de gestion de base de données relationnel. Et ben bingo c'est exactement ça et la possibilité
de s'assurer de la cohérence des données et des relations à tout moment, c'est l'avantage
principal de ces systèmes qui vous permettent en réalité de pouvoir dormir sur vos deux oreilles.
Et si jamais les performances des modèles relationnels vous font peur, rappelez-vous que
Facebook utilise un modèle relationnel comme base de données principales, ça devrait un petit peu
vous rassurer. Les non-relationnels maintenant, ces dernières années c'est vrai que les systèmes
de gestion de base de données non relationnel ont eu le vent en poupe et ont encore le vent en
poupe, notamment autour des sujets du passage à l'échelle, des systèmes distribués, du clave,
etc. Alors cette popularité, elle a joué un rôle important sur la manière dont les nouveaux
développeurs et développeuses abordent le sujet des bases de données. C'est vrai que c'est de
premier abord très très simple d'utilisation, on a la flexibilité du stockage de données non
structurées qui ont poussé beaucoup de devs à remplacer leurs bases de données relationnelles
par du non relationnel ou du SQL par du no SQL. Alors si ce remplacement y fonctionne en théorie
et il peut simplifier les choses sur des petits projets, ça revient en réalité à couper la
branche sur laquelle on se trouve, parce qu'on se prive au moins en partie des concepts de
cohérence et de durabilité des données. Alors pour répondre à la question un peu initiale de cet
épisode, c'est est-ce qu'on doit choisir du SQL ou du no SQL ? Eh bien je vais vous présenter
quelques cas d'usage très simples, on va pouvoir privilégier les bases de données no SQL. Quand
on va faire notamment du temps réel, on a des bases de données qui sont spécialisées justement
avec des mécanismes de push et pull qui vont vous permettre de faire du temps réel très facilement.
Du big data, effectivement, quand on a une quantité gigantesque de données et le big data il y a
beaucoup de données non structurées, ça peut vraiment être un plus. Quand on fait de la gestion
de cache par exemple, on va mettre en cache des pages complètes, des requêtes complètes,
et bien il y a certains systèmes de bases de données qui sont très très très rapides et très
efficaces pour ça. Donc on va pouvoir s'en servir. Ça peut être la gestion des sessions utilisateurs
qui revient un petit peu à faire de la gestion de cache, mais c'est pas exactement la même chose,
et il y a plein d'autres cas d'utilisation. Mais il est bon de noter qu'en général dans un projet,
une base no SQL, ça ne vient pas remplacer une base de données relationnelle, mais ça
vient plutôt en complément justement de cette base relationnelle. Alors si jamais vous voulez
découvrir un exemple de base de données no SQL avec la présentation de quelques cas d'usage,
je vous mettrai en lien dans les notes de l'épisode un article où je fais une introduction à Redis
qui est très très efficace pour plein de cas d'usage, mais vous verrez aussi que c'est pas
adapté à tous les usages, notamment par le relationnel. Alors en conclusion, si on devait résumer,
eh ben 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, quand on parle de valeur,
c'est la valeur pour une entreprise, pour un utilisateur, c'est quand on apporte de la valeur
et quand cette valeur dépend des relations qui doivent être stockées dans une base de données,
on parle justement de base de données relationnelle, on va simplifier avec SQL,
pour les autres données de votre modèle du domaine, si vous en avez, qui sont indépendantes les
unes des autres ou bien qui sont liées à des contraintes techniques, comme j'ai dit au cache de
sessions, cache, non-real, etc. Alors là on peut se poser la question d'une base de données non
relationnelle et donc no SQL, il faudra réfléchir à celle qui correspond le plus à vos besoins,
parce qu'il faut garder en tête aussi que no SQL, ça ne désigne même pas un type de base de données,
puisque dans les bases de données no SQL, il y a encore énormément de choix, on a des bases de
données de documents, on a des bases de données clés valeurs, c'est le cadre edis, on a des bases
de données de graphes, où là c'est pas du SQL mais c'est quand même un peu relationnel, donc voilà,
il y a énormément, énormément, énormément de choix et il faut faire les bons choix techniquement
en fonction de votre projet. J'espère que cet épisode vous aura plu, que vous en aurez appris un
petit peu plus sur les bases de données no SQL mais surtout savoir un petit peu quand on est
choisis. Moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode du podcast ou
directement sur code-h.fr, on vient de sortir de nouvelles fonctionnalités notamment pour les devs
qui recherchent des missions, des alternances ou même carrément un job, on a le listing de tous
nos membres où on peut rechercher et on peut voir les membres qui sont mis en avant par la plateforme
parce qu'ils ont une grosse activité sur la plateforme, donc n'hésitez pas à venir faire un tour,
vous pouvez construire votre portfolio en plus de suivre les cours pour afficher les certificats
de validation sur vos profils. C'est vraiment une plateforme complète et qu'on essaie de rendre
indispensable à votre vie de devs, donc venez faire un tour et on vous accueillera du mieux qu'on peut.
Moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode du podcast, salut !
Episode suivant:
Les infos glanées
Code-Garage
Découvrons ensemble des sujets passionnants autour du métier de dev et de la programmation en général !
Tags
Interview de Alex Moulinneuf, le papa du projet fou : MarioKart3.js