Nous pouvons faire mieux que SQL qui présente quelques lacunes
Selon Elvis Pranskevichus

Le , par Bill Fassinou

47PARTAGES

10  1 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de NotAèfka
Membre régulier https://www.developpez.com
Le 12/05/2019 à 8:53
Nous pouvons faire mieux que html surtout.
Avatar de pachot
Expert confirmé https://www.developpez.com
Le 12/05/2019 à 10:24
Je suis très étonné de voir cet article (je parle de l'original) en 2019. La tendance 'NoSQL' initiée par ceux qui n'ont pas compris/appris SQL (comme l'auteur le l'article) n'a pas duré longtemps. Aujourd'hui, toutes les solutions alternatives reviennent au SQL, que ce soit pour le BigData ou l'OLTP (exemple: Spark, Kafka, Spanner,...). On voit bien l'incomprehension (sur le language et le relationnel) de l'auteur de l'article dans ses exemples 'orthogonalité'. Vouloir remplacer une variable 'scalar expression' par 'table expression' c'est comme confondre une variable avec un tableau d'enregistrements...
Et proposer une base de donnée 'relationnelle-objet' en 2019... c'est idée révolutionnaire des années 80! Aujourd'hui, les bases de données objet sont mortes, et les extensions relationnel-object' jamais utilisées.
Mais le résumé est très bien. C'est sur l'article de Elvis Pranskevichus et l'idée de EdgeQL que je suis très sceptique...
Avatar de MaximeCh
Membre éclairé https://www.developpez.com
Le 12/05/2019 à 11:06
Citation Envoyé par pachot Voir le message
...
Joli analyse.
Je trouve que - ou plutôt je cherche à comprendre pourquoi - SQL a une lacune immense : il est pas du tout utilisé en OLAP, en BI, bref en analyse sérieuse des données.
Pour un langage qui s'appelle search query, et dont le sous-ensemble le plus solide, mature, standard, est le Data Query Language, c'est quand même un comble!
Ca fait un moment que je me demande si ce n'est pas lié au fait que les big brains, Codd, Date... ont écarté les logiques d'ordre supérieur...
Avatar de pachot
Expert confirmé https://www.developpez.com
Le 12/05/2019 à 11:38
Citation Envoyé par MaximeCh Voir le message
Pour un langage qui s'appelle search query
Non. 'Structured Query Language', pas 'Search'. C'est un language structuré (=qui suit la sémantique des opérations d'algèbre relationnelle) qui est utilisé pour toute définition et manipulation de donnée. Avec deux déclinaisons: pour programmer (curseurs, bind variables,...) et pour utilisation ad-hoc par l'utilisateur final - exactement la BI.
Citation Envoyé par MaximeCh Voir le message
SQL a une lacune immense : il est pas du tout utilisé en OLAP, en BI, bref en analyse sérieuse des données.
Alors là je ne comprend pas d'où vient cette idée. Justement, l'indépendance entre le modèle physique et logique, et le fait que ce soit un language déclaratif (l4G) sont les clés la clé de son utilisation en BI. Avec un language procédural (l3G) on doit connaitre à l'avance comment vont être interrogées les données, pour coder l'accés. Avec un L4G, comme SQL, on décrit seulement le résultat et l'optimiseur construit le plan d'exécution (procédural) pour aller chercher les données.

SQL:2003 définit les functions analytiques (window function) et la plupart des SGBD les implémentent aujourd'hui. C'est la clé de la BI. Toute la BI aujourd'hui utilise SQL. Soit par des SGBD relationnels qui l'ont depuis toujours, soit par les nouveaux Big Data qui l'ont adopté. Faire du code procédural pour analyser des données non structurées n'est efficace que pour un use-case donné. Les requêtes ad-hoc c'est toujours le domaine de SQL.

Je suis curieux de savoir d'où vient cette idée que SQL n'est "pas du tout utilisé en OLAP, en BI".
Avatar de MaximeCh
Membre éclairé https://www.developpez.com
Le 12/05/2019 à 11:48
Citation Envoyé par pachot Voir le message
Non. 'Structured Query Language', pas 'Search'.
Oulà oui, pas réveillé...
Citation Envoyé par pachot Voir le message
SQL:2003 définit les functions analytiques (window function) et la plupart des SGBD les implémentent aujourd'hui. C'est la clé de la BI. Toute la BI aujourd'hui utilise SQL. Soit par des SGBD relationnels qui l'ont depuis toujours, soit par les nouveaux Big Data qui l'ont adopté. Faire du code procédural pour analyser des données non structurées n'est efficace que pour un use-case donné. Les requêtes ad-hoc c'est toujours le domaine de SQL.

Je suis curieux de savoir d'où vient cette idée que SQL n'est "pas du tout utilisé en OLAP, en BI".
Les window functions font du bien au langage c'est sûr.
Dans toutes les boîtes où j'ai travaillé, on m'a asséné qu'on faisait pas de BI en SQL, parce que SQL ne gère pas les (hyper)cubes, (et que de toutes façons il fallait utiliser M$ PowerBI).
Bon c'est sûr dans ces entreprises, même à la DSI, il n'y avait pas de génies de l'informatique, mais il doit y avoir un fond de vérité...
Edit : deux liens, cubes OLAP et MDX.

Edit 2: Pour résumer ce que j'ai vu, le SQL est utilisé pour extraire des ERP, xMS, APS &co vers un datawarehouse, et ensuite les outils/langages dédiés prennent le relai.
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 12/05/2019 à 12:05
Sceptique par ce EdgeSQL. A vouloir améliorer le SQL, ce qui est toujours louable dans les intentions, on finit toujours par ajouter une nième variante à SQL ce qui est la plaie quand il s'agit de bosser sur des systèmes hétérogènes avec des SGBDR différents.

Le SQL a ses lacunes, mais quand je vois que beaucoup ont du mal avec la simple approche relationnelle, le EdgeSQL à vouloir faire quelque chose de compact et d'élégant (ce qu'il est peut-être, je n'ai lu qu'en diagonal les exemples), me semble complètement hors de portée intellectuellement parlant pour les développeurs sous-payés et sous-formés à qui on demande de pisser de la requête à l'arrache.

En résumé, bien tenté, mais aucune chance de percer.
Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 12/05/2019 à 17:26
Citation Envoyé par yahiko Voir le message
. A vouloir améliorer le SQL, ce qui est toujours louable dans les intentions, on finit toujours par ajouter une nième variante à SQL
ça me fait un peu penser à cet strip d'XKCD :

Avatar de esperanto
Membre éclairé https://www.developpez.com
Le 12/05/2019 à 18:17
Citation Envoyé par Bill Fassinou Voir le message
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.
C'est vrai que les expressions de type WITH sont arrivées assez tardivement et que même maintenant qu'elles sont là, elles restent difficiles à écrire et verbeuses.
Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)

Citation Envoyé par Bill Fassinou Voir le message
« La raison principale est que SQL, conformément à ses objectifs initiaux, s'efforce d'être une langue 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
C'est vrai que par beaucoup d'aspects SQL me fait penser à COBOL: par exemple quand on regarde les types de données avec un nombre de chiffres plutôt qu'un nombre de bits. Heureusement qu'on n'a plus à se farcir les packed-decimal, manquerait plus que ça.

Citation Envoyé par Bill Fassinou Voir le message
Pour remédier à ces différents soucis [...] Sa solution à lui, c’est EdgeQL
Intéressant, c'eut été encore mieux de mettre au moins un lien dans l'article pour qu'on puisse comparer. Surtout que dans l'original en anglais, il semble bien y avoir des exemples. Bon je vais chercher et étudier ça de plus près, difficile de se faire un avis sinon.

Citation Envoyé par pachot Voir le message
La tendance 'NoSQL' initiée par ceux qui n'ont pas compris/appris SQL (comme l'auteur le l'article) n'a pas duré longtemps.
C'est cela, oui...
C'est surtout que les communicants des grands vendeurs de bases SQL n'ont pas tardé à réagir et à faire croire aux décideurs des grandes entreprises qu'ils pouvaient faire la même chose. De toute façon les décideurs de grandes entreprises écoutent toujours en priorité ceux qui sont déjà leurs fournisseurs (contrairement aux startups, qui ont au moins le mérite de réellement s'intéresser à la technique)

Vous vous rappelez des bases de données objet, de l'organisation ODMG?
A l'époque, les experts SQL ont réussi à faire croire à tout le monde que ce modèle était plus lent que le leur. En réalité, quand on examinait les benchmarks, on se rendait compte que ceux-ci comparaient une base SQL spécialement optimisée pour le problème à résoudre avec un modèle objet écrit par un étudiant qui ne savait pas encore vraiment ce qu'était une classe. Les dés étaient donc pipés dès le départ.
Résultat:
  1. Même l'extension objet de SQL, dite relationnelle-objet ou SQL 3, bien qu'il s'agisse du dernier standard officiel, est encore passablement ignorée de la plupart des DBA. Il m'est déjà arrivé de venir avec un modèle SQL 3 pour un projet et de le voir converti par le DBA qui n'y comprenait rien...
  2. Comme entre temps les langages comme Java ont fini par supplanter Cobol, mais que les DBA ne veulent pas de SQL 3, on a fini par se retrouver avec des saloperies genre Hibernate (désolé mais même si je suis développeur et pas DBA, je comprends quand même suffisamment le modèle pour voir au premier coup d’œil que les requêtes générées par Hibernate sont non seulement pas optimisées mais probablement pas optimisables non plus...)


Citation Envoyé par pachot Voir le message
Aujourd'hui, toutes les solutions alternatives reviennent au SQL, que ce soit pour le BigData ou l'OLTP (exemple: Spark, Kafka, Spanner,...)
Évidemment, les promoteurs de SQL ont su comment réagir: en créant d'abord un type XML, puis JSON. Maintenant je suis sûr qu'on va voir fleurir les bases SQL avec une seule table ayant un seul champ de type JSON (je caricature à peine)

Sauf que si tu connaissais vraiment aussi bien NoSQL que tu prétends connaître SQL, tu saurais que le typage fort - qui n'est plus pertinent quand les données sont trop hétérogènes - n'était qu'une partie du problème auquel NoSQL essaie de répondre. Je n'ai par exemple jamais vu de base SQL répartie qui accepte de sacrifier la cohérence pour la rapidité, ce qui est parfois utile (parfois je préfère recevoir rapidement une donnée un peu ancienne que d'attendre que toutes les bases aient été rafraichies pour être sûr d'avoir la plus récente).
Avatar de pachot
Expert confirmé https://www.developpez.com
Le 12/05/2019 à 19:00
Citation Envoyé par esperanto Voir le message
Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)
presque une traduction mot à mot du language humain:

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
 
with 
"recherche exacte" as (
  select * from DEMO where TEXT='SQL'
  ), 
"recherche approximative" as (
  select * from DEMO where TEXT like '%SQL'
  )
select * from "recherche exacte" R1
union all
select * from "recherche approximative" R2
where (select count(*) from "recherche exacte")=0
;
exemple: http://sqlfiddle.com/#!4/d5818/3
Regarde le plan d'exécution: le full scan n'est exécuté que si la recherche exacte, via index, n'a rien trouvé. On ne peut pas faire plus optimal.

Sur les SGBDOO et le NoSQL, je crois plus à un point de vue pragmatique performance/consistence/agilité plutôt qu'un complot des éditeurs. Et sur le "typage fort qui n'est plus pertinent..." on en reparle quand dans 10 ans quand il faudra scanner les données hétérogènes pour trouver ce qui ressemble à un nom pour raison GDPR ou à un numéro de carte bancaire pour raison de sécurité. Oh, et "les types de données avec un nombre de chiffres plutôt qu'un nombre de bits" ils sont indispensable pour compter sans erreur d'arrondi, parce que les humains et les banquiers ne comptent pas en bits, et aiment bien les comptes justes. Les startups peuvent partir sur du NoSQL pour compter les likes, mais ils n'ont pas mis leur ERP sur MongoDB
Avatar de esperanto
Membre éclairé https://www.developpez.com
Le 12/05/2019 à 20:43
Citation Envoyé par pachot Voir le message
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
 
with 
"recherche exacte" as (
  select * from DEMO where TEXT='SQL'
  ), 
"recherche approximative" as (
  select * from DEMO where TEXT like '%SQL'
  )
select * from "recherche exacte" R1
union all
select * from "recherche approximative" R2
where (select count(*) from "recherche exacte")=0
;
J'ai dit difficile, pas impossible. Dans ton expression on a quand même 4 "select *", ça pourrait être fastidieux si on devait énumérer les mêmes champs à chaque fois... surtout que UNION ALL impose une structure identique, ce qui montre bien que ce serait bien de factoriser.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web