Ao usar o DuckDB para trabalho analítico,
senti que era possível fazer bastante coisa só com SQL.
Mas, pessoalmente,
quando eu usava SQL, quanto mais longo ficava o processo de análise,
mais eu acabava repetindo o padrão de usar cada vez mais CTEs.
Isso porque, se eu não nomeasse e fixasse os estados intermediários,
ficava fácil até para mim mesmo perder de vista
a ordem de raciocínio com que construí essa consulta.
Por que a sintaxe do dplyr veio à mente
Talvez por eu ser um usuário de longa data de R,
a sintaxe do dplyr para lidar com tabelas em etapas,
como filter → mutate → group_by → summarise,
continuava voltando à minha cabeça.
Dá para fazer o mesmo trabalho em SQL,
mas eu sentia que era um pouco inconveniente
deixar no código, exatamente como está, a ordem do raciocínio.
Então fiz um pequeno experimento sobre o DuckDB
Eu não queria colocar o runtime do R de volta,
e também era difícil transmitir essa sensação apenas com explicação,
então criei um pequeno experimento em forma de extensão do DuckDB
que converte um pipeline no estilo dplyr em SQL.
No momento, ele lida apenas com o seguinte:
select,filter,mutatearrangegroup_by,summarise- funções básicas de agregação
Joins ou reestruturações mais complexas (como pivot etc.) ainda não são tratados.
Também não é um projeto com o objetivo de compatibilidade completa com o dplyr.
Por enquanto, ainda é um experimento que surgiu do meu desconforto pessoal,
então também tenho curiosidade sobre a opinião de quem já passou por uma dúvida parecida.
Ainda não há comentários.