BigQuery prend désormais en charge la syntaxe SQL en pipe

Qu’est-ce que la Pipe Query Syntax ?

• Une extension de GoogleSQL qui permet d’écrire des requêtes dans une structure linéaire, plus lisible et plus facile à maintenir
• Prend en charge les mêmes opérations que le GoogleSQL existant (Standard SQL) : sélection, regroupement, jointure, filtrage, etc.
• Permet de définir librement l’ordre des opérations et d’écrire des requêtes complexes sans sous-requêtes imbriquées

Standard SQL vs Pipe Query Syntax

• Standard SQL
  • Doit suivre un ordre de syntaxe précis
  • L’utilisation de multiples agrégations nécessite des CTE (Common Table Expressions) ou des sous-requêtes imbriquées
  • Il faut répéter les mêmes colonnes dans SELECT, GROUP BY et ORDER BY
• Pipe Query Syntax
  • Les opérateurs pipe peuvent être appliqués dans n’importe quel ordre
  • De multiples agrégations peuvent être réalisées simplement en ajoutant des opérateurs pipe
  • Il suffit de déclarer les colonnes une seule fois

Structure de base de la Pipe Query Syntax

• 1. Commencer par la clause FROM
• 2. Ajouter une opération après |> (opérateur pipe)
• 3. Enchaîner plusieurs opérateurs |> pour construire la requête étape par étape
     (ex. : il est possible de changer l’ordre entre filtrage → agrégation → jointure)
• Caractéristiques clés
  • Il est possible d’ajouter des opérateurs pipe à n’importe quelle requête → une requête GoogleSQL existante peut être étendue en ajoutant un opérateur |> à la fin
  • L’ordre des opérations est libre → les opérateurs peuvent être appliqués dans l’ordre souhaité, autant de fois que nécessaire
  • Utilisable dans tous les environnements compatibles avec GoogleSQL → requêtes, vues, fonctions renvoyant des tables, etc.
  • Peut être mélangée avec la syntaxe SQL existante → une sous-requête peut être en Standard SQL tandis que la requête principale utilise la syntaxe pipe
  • Toutes les alias définis à l’étape précédente peuvent être référencés
  • La requête peut commencer par une clause FROM → puis être étendue progressivement en ajoutant des opérateurs |>

Différences entre la Pipe Query Syntax et le Standard SQL

• Une requête peut commencer par la clause FROM
• L’opérateur pipe SELECT n’effectue pas d’agrégation. Pour agréger, il faut utiliser séparément l’opérateur pipe AGGREGATE
• Le filtrage s’effectue avec l’opérateur pipe WHERE. Il regroupe en une seule fonction les rôles de WHERE, HAVING et QUALIFY du Standard SQL. Le filtrage peut être appliqué à n’importe quelle étape → écriture de requêtes plus flexible

Avantages de la Pipe Query Syntax

• Les requêtes peuvent être écrites dans un ordre logique → meilleure lisibilité
• Maintenance facilitée → permet d’effectuer des opérations complexes sans sous-requêtes imbriquées
• Ordre des opérations flexible → les opérations peuvent être appliquées dans l’ordre souhaité
• Filtrage plus intuitif → WHERE permet de filtrer les données à différentes étapes
• Les requêtes d’agrégation complexes sont plus faciles à écrire → l’opérateur AGGREGATE permet d’effectuer des agrégations de façon claire

La fonctionnalité est prise en charge au stade Pre-GA, avec un support encore limité

[carnoxen]

https://github.com/tc39/proposal-pipeline-operator

Un opérateur qui semble assez familier.

[halfenif]

Après avoir d’abord regardé PRQL, voir la syntaxe pipeline de Google me paraît un peu brouillon.

[GN⁺]

Avis sur Hacker News

• La syntaxe en pipeline de SQL a été implémentée dans Databricks à partir du 30 janvier 2025

  • Auparavant, il était difficile d’étendre SQL et les fonctions de valeur de table étaient complexes
  • Il est désormais possible d’effectuer l’enrichissement des données, la prédiction, le groupement, etc. avec des fonctions d’ordre supérieur
  • Par exemple, on peut filtrer les commandes après une date donnée, agréger les dépenses totales par client, puis filtrer les clients au-dessus d’un certain montant avant de faire une jointure avec les informations client
  • Le SQL itératif utilisant des pipelines peut mieux fonctionner avec la GenAI

• PRQL est une idée similaire compilée en SQL

  • Par exemple, on peut filtrer des données de facturation, calculer des commissions, puis filtrer les données dont le revenu dépasse un certain montant

• Si les extensions de syntaxe SQL continuent de se multiplier, la complexité peut augmenter

  • Il serait souhaitable que les implémenteurs SQL se concentrent davantage sur les source maps et autres mécanismes afin de mieux prendre en charge des syntaxes alternatives externes
  • Chaque projet ou individu pourrait alors choisir la variante de syntaxe SQL qui lui convient

• Lorsque la syntaxe en pipeline a été annoncée pour la première fois, l’équipe de SQLite l’a testée

  • Elle a constaté que le caractère pipeline n’était pas indispensable et que la syntaxe fonctionnait même lorsqu’il était optionnel
  • Personnellement, je trouve cette approche plus élégante visuellement

• PRQL est une syntaxe orientée pipeline pour les bases de données SQL, mais comme il s’agit d’un nouveau langage, elle n’est pas rétrocompatible avec SQL

  • Elle ne bénéficie pas du soutien de grands groupes comme Google, mais sa syntaxe est plus propre

• C’est aussi disponible dans DuckDB

• Saisir ">" après le pipeline peut être fastidieux

• Le langage Malloy n’utilise pas une syntaxe en pipeline, mais propose une syntaxe analytique similaire

  • Il a été développé par Lloyd Tabb, cofondateur de Looker

• Depuis que j’utilise Kusto Query Language, j’espère que SQL adoptera ce type de fonctionnalité

  • Si suffisamment de bases de données le prennent en charge via des extensions, cela pourrait devenir possible