SQLs Probleme und Lösungsansätze: Die Pipe-Syntax in SQL

• SQL ist seit 50 Jahren die grundlegende Sprache für die Verarbeitung strukturierter Daten, ist aber schwer zu erlernen, umständlich zu verwenden und schwer zu erweitern
• Probleme des bestehenden SQL: erzwungene Syntaxreihenfolge, redundante Syntax, notwendige Verwendung von Subqueries, Datenfluss „von innen nach außen“, mangelnde Erweiterbarkeit usw.
• GoogleSQL verfolgt einen Ansatz zur Erweiterung von SQL, um diese Probleme zu lösen
  • Es soll eine Pipe-Struktur für die Datenfluss-Syntax in SQL eingeführt werden, um die Probleme des bestehenden SQL zu beheben
  • SQL lässt sich dadurch flexibler erlernen und verwenden, während das bestehende Ökosystem erhalten bleibt und vollständige Kompatibilität zu bestehendem SQL gewahrt wird
    • Bestehende SQL-Operatoren werden wiederverwendet und können per Pipe in beliebiger Reihenfolge zusammengesetzt werden
    • Jeder Pipe-Operator kann nur die Eingabetabelle sehen, wodurch der Geltungsbereich klar definiert ist
    • Die deklarative Semantik bleibt erhalten
    • Eine Eins-zu-eins-Entsprechung zur relationalen Algebra wird möglich
    • Die Erweiterbarkeit durch Table-Valued Functions wird verbessert
  • So lassen sich beispielsweise mehrstufige Aggregationen ohne Subqueries fortlaufend ausdrücken
  • SQL mit Pipe-Syntax ist leichter zu lernen und zu verwenden; zudem steigt die Flexibilität deutlich, da verschiedene Operatoren in beliebiger Reihenfolge angewendet werden können
  • Pipe-Operatoren arbeiten sequenziell, wodurch Nutzer Daten einfacher filtern, aggregieren und sortieren können
• Nutzungserfahrungen in GoogleSQL
  • Stetige Akzeptanz durch Nutzer und positives Feedback
  • Auch komplexe Queries lassen sich linear ausdrücken
  • Erleichtert Bearbeitung und Debugging
  • Verbesserte Unterstützung durch IDE-Tools
  • Vorteile für SQL-Codegeneratoren und Konverter
  • Potenzielle Vorteile für den Einsatz von AI
• Implementierung und weitere Pläne
  • Die Pipe-Syntax wurde in GoogleSQL als gemeinsame Komponente implementiert
  • Bestehende Query-Engines können die Pipe-Syntax leicht aktivieren
  • Externe Unterstützung in BigQuery und Spanner wird geprüft
  • Es wäre erwägenswert, sie künftig in den SQL-Standard aufzunehmen

Meinung von GN⁺

• Vorteile der Pipe-Syntax: Sie kann als starkes Werkzeug zur Lösung der Komplexität von SQL dienen und insbesondere die Nutzbarkeit von SQL deutlich verbessern, weil sich Datenflüsse intuitiv ausdrücken lassen.
• Kompatibilität mit bestehendem SQL: Der Ansatz ersetzt SQL nicht, sondern verbessert es, wodurch die Lernkurve sinkt und die Kompatibilität mit bestehendem Code erhalten bleiben kann.
• Punkte für die Einführung: Bei der Einführung der Pipe-Syntax sollten die Auswirkungen auf die Performance und der Stand der Tool-Unterstützung berücksichtigt werden; insbesondere bei großen Queries können die Vorteile der Pipe-Syntax maximal genutzt werden.
• Vergleich mit ähnlichen Projekten: Auch in DataFrame-APIs wie Pandas wird eine Pipe-Struktur verwendet, der Unterschied zu SQL liegt jedoch in der Verbindung mit der deklarativen Semantik von SQL. Diese Funktionalität lässt sich nutzen, ohne Erweiterbarkeit und Performance von SQL-Systemen aufzugeben.

[dkang]

Ein Pipe mit Caret – das klingt nach einer Kombination, bei der einem irgendwie die rechte Hand wehtun könnte 🤣
Im Moment braucht SQL schon irgendeine Verbesserung.
Das Problem ist nur, dass man seit gut 30–40 Jahren keine Lösung dafür gefunden hat..

[savvykang]

Bei zusätzlicher SQL-Syntax scheint Google das Ökosystem vorantreiben zu müssen, aber wird die zuständige Geschäftseinheit das wirklich dauerhaft weiterführen?

[chusine]

Das ist wohl dplyr, hahaha

[koreaisbest]

Warum habe ich immer nur das Gefühl, dass es scheitern wird, wenn Google es macht..
Gemini antwortet außerdem wie ein nerviges Kind, deshalb will ich es auch nicht benutzen

[ilotoki0804]

Das wirkt wie ein ähnlicher Ansatz wie der, den ORMs verfolgen.

[winterjung]

Schon anhand des folgenden Beispiels aus dem Paper sieht man deutlich, dass sich Google SQL leichter lesen lässt.

Standard-SQL

SELECT c_count, COUNT(*) AS custdist  
FROM  
    ( SELECT c_custkey, COUNT(o_orderkey) c_count  
      FROM customer  
      LEFT OUTER JOIN orders ON c_custkey = o_custkey  
           AND o_comment NOT LIKE '%unusual%packages%'  
      GROUP BY c_custkey  
    ) AS c_orders  
GROUP BY c_count  
ORDER BY custdist DESC, c_count DESC;  

Google SQL

FROM customer  
|> LEFT OUTER JOIN orders ON c_custkey = o_custkey  
      AND o_comment NOT LIKE '%unusual%packages%'  
|> AGGREGATE COUNT(o_orderkey) c_count  
   GROUP BY c_custkey  
|> AGGREGATE COUNT(*) AS custdist  
   GROUP BY c_count  
|> ORDER BY custdist DESC, c_count DESC;  

[mwma91]

Erinnert mich an LINQ in C#. Immer wenn ich SQL benutze, dachte ich, es wäre schön, wenn die Reihenfolge bei SELECT immer so geändert wäre, dass es erst nach FROM und WHERE kommt....
Auch wenn es anfangs ungewohnt und deshalb etwas befremdlich wirkt, fühlt sich der Ablauf beim langsamen Lesen viel natürlicher an.

[regentag]

Ich finde, die SQL-Seite ist leichter zu lesen.

[leftliber]

Ich finde SQL deutlich leichter zu lesen. Haha, für Leute, die mit SQL angefangen haben, gilt das wahrscheinlich meistens auch ...

[superwoou]

Für mich ist Vertrautes auch leichter zu lesen … haha

[GN⁺]

Hacker-News-Kommentare

• Die SQL-Pipe-Syntax ist besser lesbar geworden
• Bei Google war die Pipe-Syntax beim Schreiben von SQL-Abfragen nützlich
• Es wäre wünschenswert, wenn sich die SQL-Pipe-Syntax allgemein durchsetzen würde
• Das Ergebnis beim Konvertieren von PDF zu HTML in Google AI Studio war gut
• Ich verwende SQL seit über 20 Jahren, habe aber immer noch Schwierigkeiten, bestimmte Abfragen auszudrücken
• Googles Open-Source-Projekt ZetaSQL hat Dokumentation zur Pipe-Syntax hinzugefügt
• Unzufriedenheit mit der Syntax von SQL hat niedrige Priorität
  • Benötigt werden Funktionen wie algebraische Datentypen, echte boolesche Logik und funktionale Komposition
• Es gab viele Versuche, die Schwierigkeiten beim Schreiben von SQL zu verringern, aber keiner war erfolgreich
  • Der Ansatz der Autoren ist schrittweise und für bestehende SQL-Nutzer geeignet
• Pipeline-Syntax ist besser als der aktuelle Zustand
  • Noch besser wäre eine Syntax, die die Ausführung von Abfragen als gerichteten Arbeitsgraphen modelliert
    • Joins lassen sich als „Querverweis“-Operation modellieren, die zwei oder mehr Datenströme konsumiert und einen Datenstrom erzeugt
    • CTEs lassen sich als Erzeugung mehrerer Datenströme modellieren
    • Rekursive CTEs lassen sich als Zyklen im Ausführungsgraphen modellieren
• Erinnert an Elixir
  • Wenn die bestehende SQL-Syntax unterstützt wird, ist das in Ordnung, aber Abfragen mit mehreren JOINs, Unterabfragen und Aggregationen können schwer lesbar werden
• Erinnert an PRQL und Splunks SPL