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 : | Sélectionner tout |
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()
} |
| Code : | Sélectionner tout |
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 |
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 |
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 |
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 
Envoyé par Bruno
) qui ne peuvent compter sur l'autocomplétion proposée par leur IDE lors de l'écriture des requêtes.
