C’est incroyable à quel point nous oublions notre propre histoire. Beaucoup de gens pensent que les bases de données NoSQL sont la « prochaine nouveauté » de la technologie et que nous devrions écrire toutes nos applications principales en les utilisant. Cependant, les bases de données NoSQL sont en fait antérieures aux bases de données relationnelles, et des bases de données relationnelles communes ont été établies pour résoudre les problèmes que NoSQL apporte.
Quels sont les avantages des bases de données NoSQL ? Il y en a essentiellement deux – ils sont rapides, rapides, rapides et ils peuvent évoluer, évoluer, évoluer. C’est vrai. Cependant, si vous ne construisez pas le prochain Facebook, vous n’avez probablement pas besoin d’autant de vitesse et d’échelle. Le fait est que cette vitesse et cette échelle ont un coût et, même dans les années 1970, avec le nombre limité d’ordinateurs disponibles à l’époque, il a généralement été décidé que la vitesse et l’échelle de ces bases de données ne valaient pas la complexité nécessaire. pour les gérer.
Avant les années 1970, deux technologies de bases de données prédominaient : le modèle réseau et le modèle hiérarchique. Le modèle de réseau a été normalisé au sein d’un groupe connu sous le nom de CODASYL (Comité sur les langages des systèmes de données). Le modèle CODASYL est presque exactement équivalent aux bases de données NoSQL modernes telles que DynamoDB.
Le problème des modèles de base de données réseau est en fait très connu :
- Le manque de normalisation des données signifie que les données sont répétées dans la base de données et oblige le programmeur à se souvenir de tous les emplacements où elles sont stockées et à les tenir à jour.
- Les modèles d’accès aux données doivent être prédéfinis. L’ajout de nouveaux modèles d’accès aux données nécessite souvent des mises à jour majeures de la structure de données sous-jacente.
- La rétrocompatibilité est difficile à maintenir. Les modifications de la base de données nécessitent des modifications simultanées du code. Dans une base de données relationnelle, les accès peuvent être effectués via des vues qui fournissent des portails spécifiques à l’application dans les données.
NoSQL conduit souvent à des bases de données entièrement différentes à des fins différentes. Étant donné que les données doivent être stockées d’une manière similaire à la manière dont elles sont utilisées, vous vous retrouvez souvent avec les mêmes données stockées dans différentes bases de données pour le traitement des transactions, l’analyse opérationnelle et l’analyse commerciale, alors qu’en SQL, elles sont toutes partager une base de données commune.
Au début des années 1970, EF Codd a développé l’idée des bases de données relationnelles comme solution à ces problèmes, et, dans les années 1980, SQL a été normalisé comme langage commun utilisé pour accéder à ces bases de données. Non seulement les bases de données relationnelles résolvent ces problèmes, mais elles fournissent un cadre théorique pour comprendre, modéliser et manipuler des données qui fonctionne pour presque toutes les situations. NoSQL prend tous ces gains et les jette essentiellement à la poubelle.
De plus, les bases de données NoSQL modernes n’offrent pas les mêmes garanties de cohérence que les bases de données relationnelles modernes. Les bases de données relationnelles modernes suivent la norme ACID. Chaque transaction est atomique (se produit en une seule fois ou pas du tout), cohérente (toutes les données validées suivent toutes les règles d’intégrité), isolée (réduit les problèmes de concurrence) et durable (si une transaction indique qu’elle a été validée avec succès, même en cas de panne du système, vous ne le perdrez pas). Ces garanties ne sont pas disponibles dans la plupart des bases de données NoSQL.
En bref, la plupart de ce qui s’est passé dans le mouvement NoSQL est simplement un oubli des raisons pour lesquelles nous sommes passés aux bases de données relationnelles pour commencer.
Cela ne signifie pas qu’il n’y a aucune utilisation de bases de données non relationnelles. Le fait, cependant, est que les bases de données NoSQL sont presque par définition une solution spécialisée. Si vous ne rencontrez pas de problèmes très spécifiques résolus par une base de données NoSQL, leurs limites l’emportent largement sur leurs avantages. Vous êtes beaucoup plus susceptible de vous retrouver dans une situation où vous avez besoin de flexibilité que dans une situation où vous avez besoin d’une vitesse d’accès au disque brute plus élevée. Les développeurs (et les entrepreneurs) aiment s’imaginer comme le prochain Facebook ou Google, mais la réalité est que développer pour cette cible avant d’y arriver est un recette pour un désastre. Vous devriez presque toujours commencer avec une base de données SQL et ne passer à une base de données NoSQL que si les circonstances l’exigent.
Vous pourriez penser, “nous devrions juste coder en utilisant NoSQL pour commencer, et ensuite ne pas avoir à le réécrire.” Cependant, le fait est que NoSQL signifie que vous le réécrirez continuellement. Une base de données relationnelle simple vous offrira le plus de flexibilité sur plusieurs ordres de grandeur, tandis qu’une base de données NoSQL vous obligera à réécrire de grandes parties de votre base de données et de votre code presque continuellement.