Discussion :

[Bruno]

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

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

1. Téléchargez Visual Studio Code : Télécharger Visual Studio Code ;
2. 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 ;
3. Téléchargez et décompressez les modèles d'échantillons (modèles + données) ;
4. 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 ;
5. 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Invité]

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.

[escartefigue]

Hum...

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

[AoCannaille]

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

Donc ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ^^

[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

[Anselme45]

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"

[AoCannaille]

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.

[sergio_is_back]

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 ?

[x_x_x_o]

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.

[AoCannaille]

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.

Mouais, bof comme argument. En SQL, sauf erreur de ma part, la syntaxe "select nom_table.nom_champs from nom_table" est valide. à partir de là, l’autocomplétion devrait directement fonctionner un fois tapé "select nom_table." . Et si ce n'est pas le cas, c'est un manque de fonctionnalité de l'éditeur, pas du langage...

[totolehero777]

Que c'est nul le Malloy, on ne verra jamais ça nulle part...

SQL c'est facile, efficace et puissant, aucun intérêt de vouloir inventer un truc aussi compliqué qu'inutile pour le remplacer.

[esperanto]

Ce langage informatique est notamment très utilisé par les développeurs web pour communiquer avec les données d’un site web.

A l'heure où les sites web, justement, sont bien plus prompts à passer à NoSQL que le commun des entreprises, je trouve quand même ça bien réducteur de présenter SQL sous cet angle...

la formation des programmeurs est le coût dominant pour un langage de programmation.

En tant que programmeur, pendant les cours à la fac, on m'a d'abord expliqué l'algèbre relationnelle et seulement ensuite le langage SQL. Et justement, le problème soulevé ici est que l'ordre des clauses dans SQL ne respecte pas l'algèbre relationnelle. Donc pas la manière dont un programmeur concevra une requête

Le SQL essaye de se rapprocher d'un langage naturel,

Comme le Cobol, qui date de la même époque, et justement je ne suis pas certain que ce soit une si bonne idée. A l'époque où les ordinateurs étaient peu répandus et peu performants, ça avait du sens de vouloir que l'ouvrier un peu qualifié puisse faire lui-même une requête dans le langage de la base pour vérifier le résultat de son travail. Aujourd'hui on encapsule tout dans des applis web, donc il est naturel que seuls des programmeurs maîtrisent le langage de la base (surtout qu'on ne veut peut-être pas donner accès à tous les champs) et de ne laisser aux utilisateurs un accès qu'à ce qui est pertinent pour eux.

et je trouve que l'ordre que tu propose ne s'applique ni au français, ni à l'anglais.

ça ressemblerait plutôt au japonais en effet (même si dans ce cas les particules seraient plutôt après ce qu'elles qualifient): du plus général au plus particulier. Je dis juste ça au cas où tu penserais que l'ordre proposé ne correspond pas à un langage naturel...

En SQL, sauf erreur de ma part, la syntaxe "select nom_table.nom_champs from nom_table" est valide.

Sauf que dans le from tu peux avoir des alias (from mytable m, voire même from (select ...) myAlias), auquel cas on est bien obligé d'avoir le from avant pour avoir l'auto-complétion.

[JeitEmgie]

https://www.iso.org/standard/76583.html

l'état de la prochaine version du standard...

[al1_24]

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 bénéficier de l'auto-complétion, il suffit de commencer sa requête par SELECT *, décrire la clause FROM puis revenir détailler les colonnes du SELECT. En quoi serait-ce compliqué ?

[valaendra]

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

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

Un marteau connecté. Mais il faudra apprendre à l'utiliser (notice fournie).

[valaendra]

Aujourd'hui on encapsule tout dans des applis web, donc il est naturel que seuls des programmeurs maîtrisent le langage de la base (surtout qu'on ne veut peut-être pas donner accès à tous les champs) et de ne laisser aux utilisateurs un accès qu'à ce qui est pertinent pour eux.

Les applis web manipulent de l'information (aujourd'hui souvent via des api & microservices). Le SQL manipule de la donnée, ce qui est différent

[JackIsJack]

Il y a des dizaines de langages dérivés du SQL qui lui apporte de la modularité, des variables, ... Du COBOL DB2 jusqu'à Linq... Et autant d'interprétateur (là où se situe la réelle complexité/les gains) donc ca me fait un peu peur quand les mecs disent être les premiers à innover.

[vanagreg]

L'interêt du langage SQL est qu'il proche du langage humain.

Ex:
Je SELECTionne le PRIX et la QUANTITE DEPUIS la table de VENTES OU la DATE DE VENTE est la date du jour.
Je SELECTionne les articles DEPUIS la table des ARTICLES pour lesquelles IL N'EXISTE PAS de vente dans la table de VENTES aujourd'hui.

Pourquoi le rendre moins proche en utilisant un pseudo-langage qui au final produit l'objectif inverse, à mon humble avis.

[smarties]

L'interêt du langage SQL est qu'il proche du langage humain.

Ex:
Je SELECTionne le PRIX et la QUANTITE DEPUIS la table de VENTES OU la DATE DE VENTE est la date du jour.
Je SELECTionne les articles DEPUIS la table des ARTICLES pour lesquelles IL N'EXISTE PAS de vente dans la table de VENTES aujourd'hui.

Pourquoi le rendre moins proche en utilisant un pseudo-langage qui au final produit l'objectif inverse, à mon humble avis.

Il me semble que dans mes cours de SQL, le professeur nous avait dit que le langage avait été conçu de façon à se rapprocher du langage parlé.

Sinon, pour moi le SQL n'a pas spécialement besoin de remplacement. Je dirais qu'il faudrait gommer les éléments des différents SGBD (MySQL, Oracle, PostgreSQL) dans le but d'avoir la même syntaxe partout.
Éventuellement avoir des modules normalisés serait intéressant (comme Postgis)

[François DORIN]

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é...