Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

95PARTAGES

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 pachot
Expert éminent 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".
10  0 
Avatar de pachot
Expert éminent 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
10  0 
Avatar de pachot
Expert éminent 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...
9  0 
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 :

7  0 
Avatar de pachot
Expert éminent https://www.developpez.com
Le 13/05/2019 à 10:40
Citation Envoyé par esperanto Voir le message
En fait pour cette requête en particulier il manque juste à SQL un opérateur "short circuit or", capable d'évaluer la seconde opération si et seulement si la première n'a pas suffi à décider. Peut-être pas dans le where, mais au moins en alternative au UNION ALL.
Évidemment tu vas trouver mille et une raisons pour lesquelles ça ne pourrait pas marcher, mais je crois que ce devrait être à l'optimiseur de requêtes de reconstituer la série de 4 select à partir d'une expression factorisée.
Oui, on peut l'écrire avec in OR si on préfère et l'optimiseur fera OR EXPANSION pour le transformer en UNION ALL. Et l'optimiseur fait ce "short circuit" - cf. l'opération FILTER dans le plan d'exécution Oracle.
Tout ça existe dans le language SQL. son utilité est justement de ne pas avoir à spécifier commect ce sera exécuté, mais seulement décrire le résultat que l'on cherche. Et l'optimiseur se charge d'écrire le plan d'exécution.

C'est finalement une très bonne illustration de la puissance de SQL et du relationnel par rapport aux langages procéduraux et aux modèles hierarchiques comme OO/XML/JSON.
7  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 14/05/2019 à 12:19
Citation Envoyé par esperanto Voir le message
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é)
Vous trouvez cela difficile ? Moi pas :

Code : Sélectionner tout
1
2
3
4
5
6
7
WITH
R1 AS (SELECT ...),
R2 AS (SELECT ...)
SELECT * FROM   R1
UNION ALL
SELECT * FROM   R2 
WHERE  NOT EXISTS(SELECT * FROM R1)

Encore une fois il s'agit d'apprendre le SQL !

A +

PS pour information c'est un exercice que je donne à mes stagiaires en cours avancé de SQL...
6  0 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 14/05/2019 à 15:32
Citation Envoyé par esperanto Voir le message
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é rafraîchies pour être sûr d'avoir la plus récente).
C'est bien le fond du problème. La cohérence c'est l'acidité des transactions, le rafraîchissement de bases c'est autre chose (copie, backup, peu importe).
La cohérence n'est jamais sacrifiable car c'est l'enfer de redresser une base incohérente (entrepôt de données à part).

Quant à la rapidité, je suis chez Teradata depuis deux ans environ et on est "challengé" par les architectures NoSQL qui sont "gratuites".
Chez le client où j'interviens régulièrement, à volume et cluster physique équivalent (250 To / 8 noeuds), Teradata répond de 10 à 2000 fois plus vite tout en gérant 15 fois plus de charge.
Tous les PoC volumineux (500 Go de données) commencés sur le cluster hadoop finissent toujours chez nous, car en terme de fonctionnalité, de langage, de rapidité, rien ne tient la route côté NoSQL.

C'est surtout ça la réalité du NoSQL, une fausse promesse portée par des développeurs (souvent issu du monde Java) qui savent à peine se servir d'une base de données.
Les performances du cluster hadoop sont justes correctes quand on est seul mais s'effondrent dès qu'il y a un peu de concurrence (et je parle de 10, pas de 5000).

Je ne dis pas que tout est à jeter, en terme de stockage décentralisé à bas coût c'est une bonne solution.
Faire du "schema on read" a aussi son utilité ici ou là.
Mais le travail caché derrière NoSQL est simplement gigantesque : la promesse de réduction de coût n'est jamais tenue.
6  0 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 14/05/2019 à 15:41
Citation Envoyé par MaximeCh Voir le message
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).
Je fais de la BI depuis une vingtaine d'années, je peux vous dire que cette histoire de cubes OLAP c'est la grande escroquerie de la BI.
Notoirement poussé par MS car SQL-Server car au début des années 2000 SQL-Server c'était vraiment pas folichon.

Je suis intervenu dans beaucoup de sociétés différentes, avec des bases sur SQL-Server, de l'Oracle, du PostgreSQL, du Greenplum, du Teradata, de 50 Go à 300 To.
Les seuls qui font des cubes sont les clients SQL-Server.

Ceux qui ont d'autres bases n'en ont pas besoin, un datamart étoile / flocon bien modélisé et bien implémenté fait très bien le job.
5  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 14/05/2019 à 17:10
Citation Envoyé par esperanto Voir le message
... les bases XML (et XML c'est une norme), les bases JSON (et JSON c'est une norme)...
NON, NON et NON… tois fois non !

Les SGBD XML ont existés au début des années et sont tous morts par darwinisme. Le dernier en date était Tamino d'AG Software… Compte tenu de la verbosité du stockage le volume des données stockées était le triple de celles des SGBDR et les performances catastrophique car il est extrément difficile d'indexer du XML….
Quant au XML et au JSON, ce ne sont absolument pas des normes… mais des standards. Il y a une différence fondamentale :

Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)

A +
5  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 14/05/2019 à 12:25
Citation Envoyé par tanaka59 Voir le message
Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .

Chaque société a décidé de plus ou moins faire ses propres normes.
...
Non, justement ce ne sont pas des normes, ni des standards, mais des dialectes.
Note que Oracle qui étais il y a encore quelques années, le plus indiscipliné, comble son retard :
  • COALESCE à la place DE NVL
  • CAST en remplacment des TO_...
  • CASE pour DECODE
  • L'arrivée des COLLATIONS, des noms longs et de l'opérateur APPLY….


A +
4  0