Moderne relationale Abfragesprachen: Was SQL von funktionalen Sprachen lernen kann
Things I want in a modern relational query language
SQL ist mächtig, aber seine Umsetzung ist oft klobig und veraltet. Der Autor, ein erfahrener Datenbankentwickler, skizziert, wie eine moderne relationale Abfragesprache aussehen könnte: bessere Syntax, funktionale Programmierkonzepte, transparentere Query-Planner, mächtigere benutzerdefinierte Typen, Summentypen mit Pattern Matching und Fremdschlüssel, die auf mehrere Typen verweisen können. Seine Vorschläge basieren auf realen Problemen mit MySQL, Db2 und anderen Systemen und sollen zeigen, wie relationale Datenbanken für Programmierer angenehmer zu nutzen wären.
Programmierer sind wie Kleinkinder, sie wollen ihr Kraft Dinner und nicht den Brokkoli.
- scythmic_waves
Hier gibt es einige Überschneidungen mit einigen meiner Lieblingsessays darüber, warum SQL mangelhaft ist:
https://www.scattered-thoughts.net/writing/against-sql
Dieser spezielle Beitrag endet mit einer Wunschliste, daher ist er dem ursprünglichen Beitrag am ähnlichsten. Es gibt aber auch andere auf der Seite, die ich sehr genieße (klicke auf das Home-Symbol und suche auf der Seite nach "SQL").
Meine persönliche Meinung ist, dass SQL noch lange dominieren wird, weil die Aufgabe, es zu ersetzen, aufgrund der inhärenten Komplexität von Datenbanken monumental ist. LLMs machen das noch schlimmer, weil sie wirklich gut darin sind, Prosa in SQL zu übersetzen. Jetzt, wo es weniger wichtig ist, wie nervig SQL für Programmierer ist, wird SQL mit der Zeit eher wie Assembler werden: etwas, das hauptsächlich von Computern geschrieben wird, weil es für Menschen kompliziert ist, direkt damit umzugehen. Das ist zutiefst ironisch, wenn man bedenkt, dass SQL angeblich so gestaltet wurde, dass es wie Prosa liest, d.h. einfach für Menschen zu handhaben ist.
- burakemir
Ich wäre wirklich neugierig, was der Autor des ursprünglichen Beitrags und die Leute hier von Mangle Datalog in diesem Kontext halten. Die Go-Implementierung ist hier: https://codeberg.org/TauCeti/mangle-go und die Rust-Implementierung ist hier: https://codeberg.org/TauCeti/mangle-rs
Die Implementierungen sind nicht hochperformant, aber wenn alles in den Speicher passt oder man seine Daten organisieren und über externe Abfragen integrieren kann, sollte man für viele Anwendungsfälle etwas Brauchbares bekommen.
Ich habe nicht vorgehabt, SQL zu ersetzen, und obwohl ich nichts gegen Verbreitung habe, ist das nicht der Grund, warum ich es hier teile. Das Open-Sourcing war motiviert durch den Wunsch, Datalog bekannter zu machen. Ich habe etwas recherchiert und festgestellt, dass ich eine Datalog-Implementierung mit bestimmten Eigenschaften brauchte; ich wusste sicher, dass ich für das, was ich brauchte, kein SQL verwenden wollte.
Es gibt strukturierte Typen und Rekursion und die Möglichkeit, Prädikate zu benennen und Abfragen zu komponieren ... Mangle hat einige Benutzer und es gibt ein paar Anwendungen, die den Ansatz von Abfragen als Logikprogrammierung nutzen.
Ich denke, eine Erkenntnis, die man aus dieser Diskussion ziehen kann, ist, dass eine Abfragesprache und das System (DBMS-Implementierung), zu dem sie gehört, kaum getrennt werden können, wenn es um die unvermeidlichen Leistungsanforderungen geht.
- bastawhiz
Als Meta-Kommentar: Ich kann Codeblöcke ohne Syntaxhervorhebung verarbeiten, und ich kann Codeblöcke verarbeiten, die umbrechen. Aber beides zusammen mit langen Kommentaren wird einfach zu Zeilenrauschen. Es gibt kein nützliches visuelles Signal mehr, wie man sie lesen soll. Auf meinem Telefon sind die Codeblöcke schlicht unmöglich sinnvoll zu parsen.
- mcc1ane
https://www.geldata.com/blog/we-can-do-better-than-sql
(https://news.ycombinator.com/item?id=24106608, https://news.ycombinator.com/item?id=19871051)
- weitendorf
Das klingt sehr nach Spark, bevor es so unternehmensorientiert wurde. Zu meiner Zeit haben wir Scala geschrieben, um unsere Abfragen auszuführen, und sobald wir herausgefunden hatten, wie wir unseren Compiler und unsere Laufzeitumgebung einrichten, hat es uns gefallen!
Ich habe mich in letzter Zeit mit Postgres beschäftigt und war sehr überrascht, wie einfach es ist, neue Typen/Operatoren/etc. über C-Code einzuführen. Ich rede nicht von Domänen. Schreib einfach etwas C und du kannst jeden Typ haben, den du willst. Es hat mir wirklich "Extensions" entmystifiziert; ich denke tatsächlich, dass das ein aktiv schädlicher Name ist (er klingt klobig, grob, basierend auf meiner Erfahrung mit "Extension" und "Plugins" anderswo) für das, was im Wesentlichen nur benutzerdefinierte Typen/Funktionen sind. Mehr Leute sollten versuchen, ihre eigenen Postgres-Erweiterungen zu schreiben. Es ist überhaupt nicht schwierig!
Ich koche schon seit geraumer Zeit in diesem Bereich (HDFS/spark, Apache Pinot, proprietäres Zeug, ein experimentelles funktionales ORM über SQLite). Das größte Problem ist, denke ich, die Schnittstelle zwischen den Verwaltungs-/Administrations-, Anwendungs- und "Abfrage"-Ebenen. Ich denke, etwas wie grpc/protoc (oder tatsächlich die Art, wie Spark die JVM nutzte) ist nötig, um nicht-lecke Abstraktionen und programmatischere/strukturiertere Schnittstellen von der Datenbank zu ihren Clients bereitzustellen. Ich teile gerne mehr, aber im Grunde muss die Datenbank zu allgemeinem (Meta-)Parsing mit einem reflektiven Typsystem fähig werden, denke ich.
- mikewarot
Meine Bitte ist 15 Jahre alt[1], eine Live-SQL-Erweiterung. Erlaube einer Abfrage, ein Abonnement einer Datenbank zu sein, sodass alle Updates als Deltas an einen lauschenden Client gestreamt werden. Es gab unzählige Male, in denen ich bei der Verwendung von SQL dieselbe Abfrage immer wieder ausgeführt habe, nur um dieses Delta zu erhalten/zu verarbeiten.
Wäre es nicht viel effizienter, von vornherein so zu arbeiten?
[1] http://livesql.org/ <--- nur ein paar Textabsätze von 2011
- nylonstrung
PRQL ist meiner Meinung nach einer der besten Versuche einer neuen Abfragesprache.
Ich arbeite an einer auf Lean4 basierenden Abfragesprache, die nach Substrait kompiliert; ich denke, die Macht, die sie in Bezug auf Typen und funktionale Programmierung hat, könnte die Ergonomie von SQL erheblich verbessern.
- 3eb7988a1663
Kann mir jemand erklären, warum SQL-Fehlermeldungen so schlecht sind? Ich habe routinemäßig eine monströse Abfrage, bei der die Meldung effektiv lautet: "Irgendwo illegale Syntax, Dummkopf".