La taille des données traitées par les entreprises augmente chaque jour et le Big Data est en plein essor. Les entreprises sont aujourd’hui à la recherche de solutions plus rapides, plus sécurisées et plus optimales pour manipuler toutes ses données. À cet effet, le SQL (Structured Query Language) est depuis plusieurs décennies le langage le plus utilisé pour accéder aux bases de données, mais pour certains, cela ne signifie pas nécessairement que le SQL représente le meilleur de ce que nous pouvons faire. Selon une analyse que propose Elvis Pranskevichus sur le langage de traitement de données, le langage SQL destiné aux requêtes ad hoc possédait dès le départ un bagage de problèmes graves.Le langage SQL peut être considéré comme le langage d'accès normalisé aux bases de données. Il est aujourd'hui supporté par la plupart des produits commerciaux que ce soit par les systèmes de gestion de bases de données micro tel que Access ou par les produits plus professionnels tels que Oracle, mais beaucoup commencent à juger que le langage SQL est de plus en plus inadapté pour la manipulation des nouveaux types de données que l’homme est en train de générer depuis quelques années maintenant. L’exemple premier qu’ils donnent est celui des données générées par les médias sociaux (les données audio, vidéo, et.) qui sont des données dites non structurées. L’alternative qu’utilisent certaines entreprises à ce niveau est d’analyser ces données à l’aide d’une base de données NoSQL.
De son côté et en se basant sur des tests réalisés avec PostgreSQL, Elvis Pranskevichus a essayé de regrouper les lacunes du langage SQL en quatre catégories. Il cite notamment le manque d’orthogonalité appropriée de SQL (SQL est difficile à composer), son manque de compacité (SQL est un langage volumineux), son manque de cohérence (SQL est incohérent dans la syntaxe et dans la sémantique) et sa mauvaise cohésion avec le système c’est-à-dire que le langage SQL ne s'intègre pas assez bien avec les langages et les protocoles d'application. Certaines de ces plaintes présentées ci-dessus, dit-il, concernent SQL dans son ensemble, tandis que d'autres sont spécifiques à une implémentation donnée.
Il a expliqué que l'orthogonalité dans un langage de programmation signifie qu'un ensemble relativement petit de constructions primitives peut être combiné de manière relativement réduite. Un langage avec une bonne orthogonalité est plus petit, plus cohérent et plus facile à apprendre, car il existe peu d'exceptions à l'ensemble des règles. Inversement, une mauvaise orthogonalité conduit à un langage large avec de nombreuses exceptions et mises en garde. Un bon exemple d'orthogonalité dans un langage de programmation est la possibilité de substituer une partie arbitraire d'une expression par une variable, ou un appel de fonction, sans aucun effet sur le résultat final. En SQL, a-t-il indiqué, une telle substitution générique n’est pas possible, car il existe deux types d’expressions incompatibles.
D’après lui et les propos de Pablo Atzeni, professeur à l’université de Rome et chercheur en base de données, le manque de compacité du langage SQL vient du fait que sa standardisation ou sa normalisation appartient en grande partie aux fournisseurs de bases de données, et non aux chercheurs universitaires sans intérêts commerciaux ou aux utilisateurs ayant des intérêts d'utilisateurs. Un exemple qu’il a donné par rapport à cela est que l'implémentation de PostgreSQL contient 469 mots-clés. La partie 2 seule (sur 14) de la norme SQL:2016 comprend 1732 pages. Il poursuit en disant que l’une des raisons principales à la prolifération de mots clés dans le langage est qu’on veuille faire en sorte qu’il soit adapté aux “non-professionnels”.
« La raison principale est que SQL, conformément à ses objectifs initiaux, s'efforce d'être un langage de type anglais, adaptée aux « non-professionnels ». Cependant, avec la croissance du langage, cette verbosité a contribué négativement à la capacité d'écrire et de comprendre les requêtes SQL. Nous avons appris cette leçon avec COBOL et le monde a depuis longtemps adopté des langages de programmation plus récents et plus succincts », a-t-il déclaré. Il entame par la suite sa critique sur le manque de cohérence du langage dans sa syntaxe et sa sémantique en disant que cela aggrave encore plus les choses, c'est que différentes bases de données ont leur propre version de SQL, souvent incompatible avec d'autres variantes de SQL.
À cela, un internaute a déclaré ce qui suit : « Je ne suis pas en désaccord avec le fait que SQL peut encore être amélioré. C'est l'une des principales raisons pour lesquelles j'utilise PostgreSQL en premier lieu, car de nombreuses améliorations sont disponibles en plus de SQL. Cela dit, SQL est sacrément efficace. En tant que langage, c'est la véritable colonne vertébrale d'Internet aujourd'hui. Il est lisible, explicite, assez concis et traduit naturellement la manière dont les données doivent être décomposées pour un stockage efficace et permettre une récupération plus efficace. Il existe des différences entre les implémentations de différents fournisseurs, mais cela sert à trouver des solutions à des défauts d’implémentations chez les autres fournisseurs et les améliorer pour créer un meilleur produit. Je souhaite bonne chance aux gens dans leur travail pour améliorer les choses, mais le langage sur lequel je me suis appuyé régulièrement ces dernières années est le SQL et j'ai travaillé avec beaucoup de langages. SQL est celui qui exécute le plus correctement et me laisse le moins souvent tomber ».
Elvis Pranskevichus
Selon Pranskevichus, ces différentes faiblesses que présente le SQL nuisent à l’ergonomie des différentes applications. L'orthogonalité, la compacité et la cohérence, a-t-il fait remarquer, sont les caractéristiques essentielles d'un langage de programmation facile à apprendre et à utiliser efficacement à tous les niveaux d'expertise, de taille d'équipe et de complexité du projet. Pour finir avec les critiques, il évoque le fait que le mouvement NoSQL est né en partie de la frustration suscitée par la stagnation et l’insuffisance perçues des bases de données SQL.
Pour remédier à ces différents soucis que pose le SQL que nous connaissons, ce que propose Pranskevichus est de parvenir à créer une meilleure version de SQL pour les utilisations futures et pouvoir manipuler les données de demain à bon escient. Sa solution à lui, c’est EdgeQL, un langage qui, selon lui, met l'accent sur la convivialité, la performance sans compromettre l'exactitude et résout l’ensemble des problèmes précités. D’après la documentation proposée à l’outil, EdgeDB est une base de données relationnelle-objet qui stocke et décrit les données sous forme d'objets fortement typés et leurs relations. La documentation précise qu’EdgeDB est construit sur PostgreSQL, héritant de toutes ses forces principales : conformité ACID, performances et fiabilité.
La base de données EdgeDB disposerait des caractéristiques suivantes : schéma strict et fortement typé, possède un langage de requête propre et puissant, permet de travailler facilement avec des données hiérarchiques complexes et propose un support intégré pour les migrations de schéma. La documentation de l’outil renseigne également qu’EdgeDB n'est pas une base de données graphique, les données sont stockées et interrogées à l'aide de techniques de base de données relationnelle. Contrairement à la plupart des bases de données graphiques, EdgeDB maintient un schéma strict. Il est aussi écrit qu’EdgeDB n’est pas une base de documents, mais insérer et interroger des données hiérarchiques de type document est une tâche triviale. L’autre chose qu’on peut noter également est qu’EdgeDB n’est pas une base de données objet traditionnelle. Malgré la classification, précise la documentation, il ne s’agit pas d’une implémentation de la persistance POO (programmation orientée objet).
« SQL a commencé avec l'objectif de permettre aux non-programmeurs de travailler efficacement avec les données relationnelles. Malgré ses faiblesses, il a sans doute eu un succès retentissant, la plupart des bases de données l'implémentant ou le reproduisant. Cependant, comme toute solution, SQL est confronté à une insuffisance croissante dans la prise en charge des nouvelles exigences, des nouveaux modes d’utilisation et de la productivité des utilisateurs. Il est temps que nous agissions », a conclu Elvis Pranskevichus.
Source : Billet de blog
Et vous ?
Qu'en pensez-vous ? Êtes-vous de l'avis de Elvis Pranskevichus ? Pensez-vous qu'EdgeQL puisse remplacer le SQL ? Pourquoi ?Voir aussi
AlaSQL.js, une base de données SQL JavaScript pour le navigateur et Node.js, est désormais disponible et serait rapide et très flexible La version 5.3.2 de DBeaver, l'outil de base de données multiplateforme, est disponible, tour d'horizon des principales nouveautés Google lance Cloud Firestore, une base de données de documents NoSQL sans serveur, serait-elle meilleure que Firebase ? 
Envoyé par esperanto
