SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement du langage

Par PRQL ou Malloy

Le 2022-09-08 05:16:49, par Bruno, Chroniqueur Actualités

Le SQL (Structured Query Language) est un langage permettant de communiquer avec une base de données. Ce langage informatique est notamment très utilisé par les développeurs web pour communiquer avec les données d’un site web. Toutefois, Carlin Eng, ancien ingénieur en données et responsable de l'ingénierie chez Strava estime que, « à part une poignée de mises à jour de la norme ANSI, le cœur du langage SQL ne s’est pas amélioré après quatre décennies. »

« SQL est toujours la principale interface utilisateur par laquelle la plupart des professionnels des données interagissent avec leurs systèmes. Les technologies sous-jacentes se sont améliorées de façon incommensurable, mais à part une poignée de mises à jour de la norme ANSI, le cœur du langage reste intact. C'est pratiquement un miracle qu'après plus de 40 ans d'utilisation par d'innombrables professionnels des données, SQL, l’interface avec les données, reste effectivement la même », déclare Carlin.

Carlin Eng est un ancien ingénieur en données et responsable de l'ingénierie chez Strava ; il a passé deux ans comme ingénieur commercial et scientifique des données chez Snowflake. Il est actuellement responsable de l'ingénierie des données chez Eppo. Selon Carlin, depuis la création du SQL, de nombreux informaticiens et chercheurs en bases de données ont exprimé leur dédain pour le langage, et leurs critiques sont généralement fondées ; cependant, toutes les tentatives sérieuses de le remplacer comme norme de facto ont échoué.

La plupart des tentatives de remplacement de SQL portent essentiellement sur ce que Carlin appelle « la syntaxe maladroite du langage », par exemple en plaçant la clause FROM en premier ou en supprimant la nécessité des clauses HAVING et QUALIFY. Malheureusement, la réalité est que SQL est « suffisamment bon » pour la plupart des cas d'utilisation, et selon la loi d'Aiken, la formation des programmeurs est le coût dominant pour un langage de programmation.

De l’avis de Carlin, les professionnels des données devraient se tourner vers Malloy, un nouveau langage d'interrogation pour l'analyse des données. « Malloy répond à de nombreux problèmes de conception qui affectent SQL, mais le plus intéressant à mon avis est l'intégration d'un langage d'interrogation et d'une couche sémantique en un seul langage. »

Malloy est un langage expérimental pour décrire les relations et les transformations de données. Développé par Lloyd Tabb, fondateur et ancien directeur technique de Looker, Malloy est à la fois un langage de modélisation sémantique et un langage d'interrogation qui exécute des requêtes contre une base de données relationnelle. Il se connecte actuellement à BigQuery et Postgres, et supporte nativement DuckDB. Une extension Visual Studio Code a été construite pour faciliter la conception de modèles de données Malloy, l'interrogation et la transformation de données, et la création de visualisations et des tableaux de reporting simples.

Pour essayer l'extension VSCode de Malloy

Téléchargez Visual Studio Code : Télécharger Visual Studio Code ;
Ajoutez l'extension Malloy (pre-release) à partir du marché Visual Studio Code : Ouvrez VS Code et cliquez sur le bouton Extensions à l'extrême gauche (il ressemble à 4 blocs dont un s'envole). Cela ouvrira les extensions. Recherchez Malloy et, une fois trouvé, cliquez sur Installer ;
Téléchargez et décompressez les modèles d'échantillons (modèles + données) ;
Ouvrez le dossier samples dans VS Code. Dans VS Code, allez dans Fichier > Ouvrir le dossier... sélectionnez samples/duckdb > Ouvrir. DuckDB est intégré dans l'extension, vous êtes donc prêt à les exécuter ;
Commencez avec 1_airports.malloy dans l'ensemble de données FAA. Il s'agit d'un sous-échantillon de l'ensemble de données NTSB Flights. Dans le panneau de l'éditeur, au-dessus de source : airports, cliquez sur le mot "Preview" pour exécuter un SELECT *, et cliquez sur le mot "Run" au-dessus de n'importe quel objet de requête pour l'exécuter (voir le gif ci-dessous par exemple).

Actuellement, l'extension Malloy fonctionne sur les machines Mac, Linux et Windows

Voici un exemple simple d'une requête Malloy

Code :

1
2
3
4
5
6
7
query: table('malloy-data.faa.flights') -> { 
  where: origin ? 'SFO' 
  group_by: carrier 
  aggregate: 
    flight_count is count() 
    average_flight_time is flight_time.avg() 
}

En SQL, ce serait :

Code :

1
2
3
4
5
6
7
8
SELECT 
   carrier, 
   COUNT(*) as flight_count, 
   AVG(flight_time) as average_flight_time 
FROM `malloy-data.faa.flights` 
WHERE origin = 'SFO' 
GROUP BY carrier 
ORDER BY flight_count desc         -- malloy automatically orders by the first aggregate

Malloy : langage de modélisation sémantique

Etant donné que nos systèmes informatiques ne se conforment pas toujours à la réalité, couche sémantique vient codifier la logique spécifique à un domaine au-dessus des tables de la base de données, et empêcher les utilisateurs d'émettre des requêtes qui sont syntaxiquement valides, mais sans signification sémantique.

Dans l’exemple présenté par Carlin, le cas de l’écriture d’une jointure entre deux tables dont les clés sont incorrectes, étant donné que dans la plupart des bases de données relationnelles, les clés primaires et étrangères sont simplement des chaînes de caractères ou des chiffres, certaines bases de données peuvent appliquer l'intégrité référentielle, mais la plupart ne poseront aucun souci si vous tentez de joindre, par exemple, CUSTOMER_ID avec ORDER_ID.

Autre exemple, il arrive souvent que les colonnes de clés primaires soient des nombres entiers, et les bases de données vous laisseront volontiers les utiliser comme entrées pour toute fonction d'agrégation qui prend un nombre en entrée, comme SUM ou AVG, même si le résultat est absurde. Enfin, chaque organisation a des règles spéciales qui doivent être appliquées à ses ensembles de données afin de calculer correctement les indicateurs clés.

Malloy pourrait-il finalement être le langage qui remplace SQL ?

Si la question du remplacement du langage SQL ne se pose pas pour certains, il n’en reste pas moins vrai qu’il existe des candidats sérieux à ce remplacement du langage SQL. Malloy pourrait être significativement différent « et plus utile » en raison de son inclusion d'une couche sémantique dans le langage de base. Cependant, en fouillant un peu, on verra qu’il existe également PRQL (Pipelined Relational Query Language) qui est plus intuitif et plus simple, selon l’avis de certains utilisateurs.

« C'est une tâche presque impossible pour Malloy, mais j'espère vraiment qu'il réussira. Contrairement aux autres projets qui ne cherchent qu'à améliorer l'esthétique du langage, Malloy adopte une approche plus ambitieuse et s'attaque à une pièce manquante critique de la pile », déclare Carlin.

Son mariage entre le langage de requête et la couche sémantique a le potentiel de changer radicalement les disciplines de l'analyse et de la veille stratégique pour le mieux. D'autres tendances, comme la montée en puissance et la domination de quelques produits de plateforme de données, à savoir BigQuery et Snowflake, pourraient signifier que pour que Malloy réussisse vraiment, il doit prendre en charge relativement peu de cibles de base de données.

PRQL est un langage moderne pour transformer les données. Pour certains, il s’agit d’un remplaçant simple, puissant et pipeliné de SQL. Comme SQL, il est lisible, explicite et déclaratif. Contrairement à SQL, il forme un pipeline logique de transformations, et supporte des abstractions telles que les variables et les fonctions. Il peut être utilisé avec n'importe quelle base de données qui utilise SQL, puisqu'il se transpose en SQL.

PRQL peut être aussi simple que :

Code :

1
2
3
4
5
6
7
from employees 
filter country == "USA"                       # Each line transforms the previous result. 
aggregate [                                   # `aggregate` reduces column to a value. 
  max salary, 
  min salary, 
  count,                                      # Closing commas are allowed :) 
]

Voici un exemple plus complet de ce langage :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
from employees 
filter start_date > @2021-01-01               # Clear date syntax. 
derive [                                      # `derive` adds columns / variables. 
  gross_salary = salary + (tax ?? 0),         # Terse coalesce 
  gross_cost = gross_salary + benefits_cost,  # Variables can use other variables. 
] 
filter gross_cost > 0 
group [title, country] (                      # `group` runs a pipeline over each group. 
  aggregate [                                 # `aggregate` reduces each group to a row. 
    average gross_salary, 
    sum_gross_cost = sum gross_cost,          # `=` sets a column name. 
  ] 
) 
filter sum_gross_cost > 100000                # Identical syntax for SQL's `WHERE` & `HAVING`. 
derive id = f"{title}_{country}"              # F-strings like python. 
sort [sum_gross_cost, -country]               # `-country` means descending order. 
take 1..20                                    # Ran

Sources : Malloy, Carlin Eng's blog, PRQL

Et vous ?

Cette analyse sur le remplacement du langage SQL est-elle pertinente ?

Partagez-vous l'avis selon lequel le SQL serait obsolète et nécessiterait une MAJ ?

Quel langage de requête utilisez-vous ? SQL, PRQL ou Malloy ?

Êtes-vous pour ou contre le remplacement de SQL par PRQL ou Malloy ? Selon vous, est-ce possible ?

Voir aussi :

YDB, une base de données SQL distribuée et open source, sous licence Apache 2.0, elle fonctionne sur des plateformes x86 64 bits avec un minimum de 8 Go de RAM

Il y'aurait plus de mille milliards de bases de données SQLite en utilisation active, faisant du SGBD le composant logiciel le plus largement déployé et utilisé

SQLite 3.37 est disponible, le moteur de base de données léger apporte le mode STRICT tant attendu, une amélioration de l'interface CLI et plus

PostgreSQL aurait commencé à travailler sur le support de la compression Zstandard, pour compléter toutes les possibilités de LZ4 que l'on trouve actuellement dans PostgreSQL 14

Facebook explique les défis auxquels il a dû faire face lors de la migration de MySQL 5.6 vers la version 8.0, une migration qui a duré des années avec à la clé des gains non négligeables

Discussion forum

40 commentaires

escartefigue
Modérateur

Hum...

Envoyé par Bruno

SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement du langage

"Des" c'est à minima 2, or, la dernière version de SQL est celle de 2016, on pourra donc éventuellement en reparler en 2036

Par ailleurs, remplacer SQL pourquoi ? Quelles sont les choses qu'on ne peut pas faire correctement avec SQL ?
Quand on maîtrise ce langage, je dirai pas grand chose. Les critiques viennent souvent d'un défaut de maîtrise de SQL ou d'une utilisation à contre emploi.

De plus, le patrimoine applicatif est tel qu'un changement de langage aurait un coût monstrueux.

Je crois au contraire que SQL a encore de beaux jours devant lui

le 08/09/2022 à 9:09
Je préfère largement la syntaxe du SQL aux alternatives proposées. Et pour les fonctionnalités manquantes, on a PL/pgSQL qui fait très bien le taff.

le 08/09/2022 à 9:03
sergio_is_back
Expert confirmé

A la maison j'utilise le même marteau depuis plus de 40 ans
Malgré quelques clous plantés de travers force est de constater qu'il convient toujours aussi bien

Je devrais le remplacer par quoi ? une clé à molette, une banane en mousse ?

le 08/09/2022 à 13:24

AoCannaille

Expert confirmé

Envoyé par Bruno

La plupart des tentatives de remplacement de SQL portent essentiellement sur ce que Carlin appelle « la syntaxe maladroite du langage »

Donc ça :

Code :

1
2
3
4
5
6
7
query: table('malloy-data.faa.flights') -> {
  where: origin ? 'SFO'
  group_by: carrier
  aggregate:
    flight_count is count()
    average_flight_time is flight_time.avg()
}

est sensé être moins maladroit que ça ?

Code :

1
2
3
4
5
6
7
8
9
SELECT
   carrier,
   COUNT(*) as flight_count,
   AVG(flight_time) as average_flight_time
FROM `malloy-data.faa.flights`
WHERE origin = 'SFO'
GROUP BY carrier
ORDER BY flight_count desc         -- malloy automatically orders by the first aggregate

Et bien j'en conclu que la maladresse n'est pas une notion universelle ^^

le 08/09/2022 à 9:52

Anselme45
Membre extrêmement actif

Si le SQL n'a pas subi de MAJ importantes depuis des décennies, c'est tout simplement parce que le SQL répond pleinement aux attentes de ses utilisateurs!!!!!!!!!!!!!!!!

Sortir l'argument "il faut remplacer parce que pas modifier depuis longtemps" est juste idiot!

Mais bon, l'idiot en question a obtenu ce qu'il voulait: faire parler de lui.

De ex-ingénieur, il deviendra dans quelques jours "ex-mec qui a fait parlé de lui pendant une semaine avant de sombrer dans l'anonymat qu'il n'aurait jamais du quitter"

le 08/09/2022 à 10:53
François DORIN
Expert éminent sénior

Le véritable reproche fait à SQL est fait par... des développeurs frustrés (dont je suis ) qui ne peuvent compter sur l'autocomplétion proposée par leur IDE lors de l'écriture des requêtes.

Maintenant, SQL a quand même de sacrés avantages, dont celui d'être lisible, y compris par quelqu'un qui ne connait pas SQL (il ne comprendra pas forcément toutes les subtilités bien sûr, mais il pourra grosso modo comprendre d'où viennent les données, ce qui est affiché, etc..).

Enfin, si SQL doit être remplacé "suite à l'absence de MAJ importantes depuis des décennies", il devrait en être de même pour de nombreux outils (tar, gz, cp, ...) et pleins de langages (C, Fortran, Ada pour n'en citer que quelques uns). Il est dommage de confondre obsolescence et maturité...

le 09/09/2022 à 9:16
AoCannaille
Expert confirmé

Envoyé par psancho

le principal grief que je pourrais avoir sur le SQL, c'est l'ordre des blocs.

En toute logique, on devrait avoir :

FROM
WHERE
GROUP
ORDER
SELECT

En regardant bien, c'est ce que les "nouveaux" langages et les ORM font.

Si SQL pouvait faire de même, pas besoin de plus

Le SQL essaye de se rapprocher d'un langage naturel, et je trouve que l'ordre que tu propose ne s'applique ni au français, ni à l'anglais.

Si tu vas voir un guichet de la SNCF, tu dis un truc du genre "J'aimerais les horaires de départ des trains qui vont à Marseille", ce qui fait un truc du genre "Select departure_time, from connections where destination = `Marseille`", et pas "Des trains qui partent à Marseille j'aimerais les horaires de départ" comme tu le propose.

La même chose en anglais donne "When do the next trains to Liverpool leave?" avec en premier la demande qui correspond au select (when), le "quoi" ensuite (on cherche des trains) et enfin la particularité en dernier.

Je veux bien entendre que lors de l'utilisation de requêtes plus complexe avec having, group by etc, l'ordre est moins évident, mais de mon point de vue d'utilisateur occasionnel et plutôt limité du SQL, l'ordre "Select from where" est bon.

Ceci dit, je pense que tu as raison, il y aurait peut être un moyen technique de rendre le SQL insensible à l'ordre des clauses, comme ça, tout le monde serait content.

le 08/09/2022 à 11:35
stailer
Membre chevronné

Comme dans toute appli, on a toujours les requêtes "simples"... quelques where, quelques group by.
Et puis le dév avance et il arrive le moment de la requête SQL compliqué : UNION , des vues, des filtres et des jointures avec INNER ou LEFT un peu partout parce qu'on a pas pu faire autrement... Et on a essayé de faire "bien" mais aussi un peu "vite" car les délais existent à un certain moment.

Tout ça pour dire que les exemple Malloy et compagnie c'est très joli, avec systématiquement des trucs hypers simples en exemple... Moi j'aimerais voir l'équivalent d'une bonne grosse query SQL comme on en a dans nos applis "réelles" et leur équivalent dans un autre langage.

Là seulement on pourra dire : ok l'écriture est 5 fois plus rapide et j'ai 5 fois moins de code de requête à écrire.

En attendant, lire l'équivalent d'un pauvre SELECT ... FROM table WHERE machin = 5 , il m'en faudra un peu plus pour me convaincre

le 10/09/2022 à 11:46
Gugelhupf
Modérateur
Bon, je vais rajouter mon grain de sel :
- Bien que normé ANSI en 1986, le SQL existe depuis 1974, c'est un langage d'une grande maturité
- Depuis 2003 nous avons des mise à jour (des ajouts) de la norme tous les 2-3 ans, le langage est suivi
- Certaines technos NoSQL que j'ai pu voir ont commencés avec leur propre syntaxe, pour peu à peu s'orienter vers le SQL, c'est notamment le cas de CQL (le langage de Cassandra) ou bien N1QL (le langage de Couchbase), voulaient-ils s'approprier la popularité du SQL, ou bien le SQL a dès le départ été très bien conçu par les chercheurs d'IBM ?
Pour ma part le SQL a ses subtilités, le premier venu tombera forcément dans les pièges liées aux mélanges de jointures internes et externes ou des aggrégats par groupe, tout comme le débutant C et C++ qui utilisera les pointeurs... cependant je ne connais pas de langage qui permet de manipuler aussi bien les tableaux que le SQL

Si ces gens là voulaient vraiment montrer le bienfait de leur langage, ils mettraient en avant ce que leur produit apporte de plus, de mieux que le produit existant (ici le SQL), et je ne pense pas que ce soit le cas. Du coup j'ai plutôt l'impression de voir un groupe qui veut intégrer sa solution chez les clients pour vendre de l'audit
le 09/09/2022 à 10:45
x_x_x_o
Membre à l'essai

Envoyé par AoCannaille

Le SQL essaye de se rapprocher d'un langage naturel, et je trouve que l'ordre que tu propose ne s'applique ni au français, ni à l'anglais.

Si tu vas voir un guichet de la SNCF, tu dis un truc du genre "J'aimerais les horaires de départ des trains qui vont à Marseille", ce qui fait un truc du genre "Select departure_time, from connections where destination = `Marseille`", et pas "Des trains qui partent à Marseille j'aimerais les horaires de départ" comme tu le propose.

La même chose en anglais donne "When do the next trains to Liverpool leave?" avec en premier la demande qui correspond au select (when), le "quoi" ensuite (on cherche des trains) et enfin la particularité en dernier.

Je veux bien entendre que lors de l'utilisation de requêtes plus complexe avec having, group by etc, l'ordre est moins évident, mais de mon point de vue d'utilisateur occasionnel et plutôt limité du SQL, l'ordre "Select from where" est bon.

Ceci dit, je pense que tu as raison, il y aurait peut être un moyen technique de rendre le SQL insensible à l'ordre des clauses, comme ça, tout le monde serait content.

Commencer par le from a l'avantage que dans les lignes suivantes il peut proposer l'autocomplétion.
Quand tu commences par select on ne sait pas d'où vont provenir les données donc pas possible de proposer la liste des colonnes possible afin de faciliter l'écriture de la requête.

Pour faire beaucoup de C# avec VS, l'autocomplétion est vraiment géniale et c'est frustrant quand tu écris une requête SQL pour avoir l'autocomplétion il faut d'abord écrire le from sur la 2e ligne puis tu peux écrire ton select sur la 1ere ligne pour qu'il te propose les colonnes de la table que tu as indiqué dans le from.

le 08/09/2022 à 14:23

Poster une réponse