NoSQL est plus évolutif que révolutionnaire. Il combine essentiellement les idées existantes de "stockage de base de données externe" avec "l'utilisation de structures de données familières, pas de tables relationnelles".
Il existe plus de types de bases de données que de bases de données relationnelles, par exemple les bases de données hiérarchiques . Bien qu'archaïque par rapport aux normes actuelles, il s'intègre parfaitement dans les structures de données de ses données (par exemple, les enregistrements COBOL ). Le fait est que les données de la base de données ont été modélisées en fonction de la manière dont les enregistrements ont été disposés dans les langages de programmation qui les utilisaient.
Avance rapide vers l’invention des bases de données relationnelles , où la base de données a été séparée de ses préoccupations et, bien normalisée, est un excellent moyen de visualiser la plupart des types de données et les relations entre données. C'est vraiment facile à comprendre par rapport à d'autres types de bases de données. Cependant, ce qui échoue complètement, c’est stocker les données d’une manière qui reflète les objets et les classes d’un programme. D'où l'invention du mappage objet-relationnel . En d'autres termes, la conception de la base de données est en réalité un obstacle à la conception du programme qui l'utilise. C'est pourquoi nous avons besoin de bibliothèques ORM telles que Hibernate.. Bien que propre et cohérent, il y a toujours ce doute lancinant qui me tient à l’esprit que quelque chose ne va pas tout à fait.
Cela a donné lieu à deux autres types de bases de données, les bases de données objet et NoSQL .
Les deux cherchent à résoudre les problèmes introduits par les bases de données relationnelles sans nous exposer aux horreurs hallucinantes des bases de données hiérarchiques. Les données sont toujours présentées dans des référentiels qui ressemblent vaguement à des tableaux, mais ressemblent en réalité davantage à la programmation de structures de données qu'à des tableaux relationnels. Bien que les bases de données objet suivent principalement des règles bien définies, ma compréhension est que NoSQL est plutôt arbitraire. Par exemple, une table peut être visualisée sous forme de table de hachage ou de tableau. Il n’existe pas de moyen facile et bien défini de les interroger à l’aide d’un outil arbitraire analogue à Oracle SQL Developer ou SQL Server Management Studio .
L'idée est que l'on peut définir des structures de données qui sont facilement recherchées dans le code, plutôt que de reconstituer des requêtes SQL mieux adaptées à un moteur de base de données SQL plutôt que d'exprimer la requête souhaitée. Par exemple, les correspondances floues ou partielles sont plus difficiles et moins performantes dans une base de données relationnelle, alors qu'une base de données NoSQL peut avoir une structure optimisée pour une telle recherche et se terminer en une fraction du temps.
Il existe des langues pour interroger NoSQL. Cependant, il n'existe pas de langage universel tel que SQL pour les bases de données relationnelles.
Édition tardive:
Bien que je connaisse assez bien les bases de données NoSQL, cette question m'a incité à acheter un livre de qualité sur le sujet et à commencer à le lire avec l'objectif final d'être un véritable expert du sujet. Les autres commentaires sont basés sur NoSQL Distilled: un bref guide sur le monde émergent de la persistance polyglotte par Pramod Sadalage et Martin Fowler .
Les auteurs déclarent que les bases de données relationnelles ne s'adaptent pas parfaitement aux clusters capables de fournir les données nécessaires à des sites tels qu'Amazon et Google: NoSQL a été développé pour s'adapter à ce créneau, réduisant ainsi la concurrence et la durabilité d'ACID afin de traiter utilisent largement des données statiques (les transactions ACID ne sont donc pas aussi importantes).
En outre, ils soutiennent que les bases de données NoSQL fonctionnent sans schéma (page 10), ce qui permet aux bases de données NoSQL de modifier plus facilement la structure des données. Je ne suis pas sûr que la présence ou l'absence d'un schéma formel soit important à cet égard, car les bases de données SQL permettent également de modifier les schémas. Quoi qu'il en soit, les deux auteurs renommés font cette affirmation et mérite donc d'être examinée.
Je crois que ces deux points principaux ne font que renforcer mon argument principal, à savoir que NoSQL est évolutif et non révolutionnaire. Ils stockent toujours des données et apportent des améliorations incrémentielles à l’échelle et à la possibilité de modification. Ils soulignent également que NoSQL ne cherche pas à usurper les bases de données relationnelles en tant que roi du stockage de données, mais uniquement à fournir un moyen alternatif de stockage des données pour les types de données devant être redimensionnés et transformés de manière (vraisemblablement) relationnelle. les bases de données ne supportent pas assez bien.