En utilisant DuckDB pour des travaux d’analyse,
j’ai eu le sentiment qu’on pouvait déjà faire énormément de choses avec SQL seul.
Cela dit, personnellement,
quand j’écris du SQL, j’ai constaté qu’à mesure que le processus d’analyse s’allonge,
je retombe toujours sur le même schéma : utiliser de plus en plus de CTE.
Sans nommer et figer les états intermédiaires,
il m’était facile de perdre moi-même
l’ordre de réflexion avec lequel j’avais construit cette requête.
Pourquoi la syntaxe dplyr m’est revenue à l’esprit
Sans doute parce que j’utilise R depuis longtemps,
la syntaxe dplyr pour manipuler des tables étape par étape,
comme filter → mutate → group_by → summarise,
me restait constamment en tête.
On peut faire le même travail en SQL,
mais j’avais l’impression que c’était un peu moins pratique
pour laisser dans le code l’ordre de la réflexion tel quel.
J’ai donc mené une petite expérimentation au-dessus de DuckDB
Je n’avais pas envie de réintroduire un runtime R,
et il était tout aussi difficile de transmettre cette sensation par de simples explications,
alors j’ai créé une petite expérimentation, sous forme d’extension DuckDB,
qui convertit un pipeline de style dplyr en SQL.
Pour l’instant, cela couvre à peu près les éléments suivants :
select,filter,mutatearrangegroup_by,summarise- les fonctions d’agrégation de base
Les jointures ou les restructurations plus complexes (pivot, etc.) ne sont pas encore prises en charge.
Ce n’est pas non plus un projet visant une compatibilité complète avec dplyr.
Pour l’instant, c’est une expérimentation née de ma propre frustration,
et je serais curieux d’avoir l’avis de personnes qui se sont posé des questions similaires.
Aucun commentaire pour le moment.