Während ich DuckDB für Analysearbeiten genutzt habe,
hatte ich das Gefühl, dass man allein mit SQL schon ziemlich viel erledigen kann.
Allerdings habe ich persönlich beim Schreiben von SQL immer wieder dasselbe Muster erlebt: Je länger der Analyseprozess wurde, desto häufiger habe ich CTEs verwendet.
Wenn ich Zwischenzustände nicht benannt und festgehalten habe,
war es selbst für mich leicht, den Gedankengang zu verlieren, in welcher Reihenfolge ich diese Query aufgebaut hatte.
Warum mir die dplyr-Syntax in den Sinn kam
Vielleicht, weil ich R schon lange nutze: Die dplyr-Syntax zum schrittweisen Arbeiten mit Tabellen,
wie filter → mutate → group_by → summarise,
ist mir immer im Kopf geblieben.
Dasselbe lässt sich auch mit SQL erledigen,
aber ich fand es etwas unhandlich, die Reihenfolge des Denkens direkt so im Code festzuhalten.
Deshalb habe ich ein kleines Experiment auf DuckDB gemacht
Ich wollte nicht noch einmal eine R-Runtime darüberlegen,
und gleichzeitig war es schwierig, dieses Gefühl nur mit einer Erklärung zu vermitteln.
Deshalb habe ich als DuckDB-Extension ein kleines Experiment gebaut, das eine dplyr-ähnliche Pipeline in SQL umwandelt.
Derzeit unterstützt es ungefähr Folgendes:
select,filter,mutatearrangegroup_by,summarise- grundlegende Aggregatfunktionen
Joins oder komplexe Umstrukturierungen (Pivot usw.) werden noch nicht behandelt.
Es ist auch kein Projekt mit dem Ziel vollständiger dplyr-Kompatibilität.
Im Moment ist es noch ein Experiment, das aus meinem persönlichen Unbehagen entstanden ist,
und ich bin neugierig auf die Meinungen von Leuten, die sich ähnliche Gedanken gemacht haben.
Noch keine Kommentare.