Os problemas do SQL e como resolvê-los: a sintaxe de pipe no SQL

 (research.google)
13 pontos por GN⁺ 2024-08-26 | 11 comentários | Compartilhar no WhatsApp
  • O SQL se consolidou como a linguagem básica para processamento de dados estruturados por 50 anos, mas é difícil de aprender, complicado de usar e difícil de estender
  • Problemas do SQL tradicional: imposição da ordem da sintaxe, sintaxe duplicada, necessidade de usar subconsultas, fluxo de dados “de dentro para fora”, falta de extensibilidade etc.
  • No GoogleSQL, foi adotada uma abordagem de estender o SQL para resolver esses problemas
    • Busca resolver os problemas do SQL introduzindo na linguagem uma sintaxe de fluxo de dados em estrutura de pipe
    • Isso permite aprender e usar o SQL de forma mais flexível, mantendo o ecossistema existente e compatibilidade total com o SQL atual
      • Reutiliza operadores de SQL existentes e permite compô-los em qualquer ordem com pipes
      • Cada operador de pipe enxerga apenas a tabela de entrada, deixando o escopo claro
      • Mantém a semântica declarativa
      • Passa a ser possível uma correspondência um a um com a álgebra relacional
      • A extensibilidade melhora com funções de valor de tabela
    • Por exemplo, é possível expressar agregações em múltiplas etapas de forma contínua, sem subconsultas
    • O SQL com sintaxe de pipe é mais fácil de aprender e usar, e a flexibilidade melhora bastante por permitir aplicar vários operadores em ordem arbitrária
    • Os operadores de pipe funcionam de forma sequencial, permitindo ao usuário filtrar, agregar e ordenar dados com mais facilidade
  • Experiência de uso no GoogleSQL
    • Adoção contínua pelos usuários e feedback positivo
    • Até consultas complexas podem ser expressas de forma linear
    • Facilita edição e depuração
    • Melhora o suporte de ferramentas de IDE
    • É vantajoso para geradores e conversores de código SQL
    • Há vantagens potenciais para aplicação de IA
  • Implementação e planos futuros
    • A sintaxe de pipe foi implementada no GoogleSQL como um componente compartilhado
    • Motores de consulta existentes podem ativar facilmente a sintaxe de pipe
    • Está em análise o suporte externo em BigQuery e Spanner
    • Vale explorar a possibilidade de inclusão futura no padrão SQL

Opinião do GN⁺

  • Vantagens da sintaxe de pipe: pode funcionar como uma ferramenta poderosa para resolver a complexidade do SQL, especialmente por permitir expressar o fluxo de dados de forma intuitiva, melhorando bastante a usabilidade da linguagem.
  • Compatibilidade com o SQL existente: a proposta não substitui o SQL atual, mas o aprimora, reduzindo a curva de aprendizado e mantendo a compatibilidade com código já existente.
  • Pontos a considerar na adoção: ao adotar a sintaxe de pipe, é preciso considerar o impacto em desempenho e o nível de suporte das ferramentas; especialmente em consultas de grande escala, é possível aproveitar melhor suas vantagens.
  • Comparação com projetos semelhantes: APIs de DataFrame, como Pandas, também usam estrutura de pipe, mas o diferencial aqui é a combinação com a semântica declarativa do SQL. Assim, é possível usar esse recurso preservando a extensibilidade e o desempenho dos sistemas SQL.

Leituras relacionadas

11 comentários

 
dkang 2024-08-26

Um acento circunflexo no pipe... parece uma combinação que vai fazer a mão direita doer 🤣
Realmente é preciso melhorar alguma coisa no SQL.
O problema é que não conseguiram encontrar uma proposta de melhoria em uns 30 ou 40 anos...
 
savvykang 2024-08-26

Parece que, em relação à sintaxe adicional do SQL, o Google deveria liderar o ecossistema, mas será que a divisão de negócios vai sustentar isso?
 
chusine 2024-08-26

É o dplyr mesmo kkkkk
 
koreaisbest 2024-08-26

Por que, quando o Google faz isso, eu só fico com a sensação de que vai dar ruim..
O Gemini responde como uma criança, então nem dá vontade de usar
 
ilotoki0804 2024-08-26

Parece bem semelhante à abordagem adotada pelos ORMs.
 
winterjung 2024-08-26

Só de olhar o exemplo abaixo no paper já dá para ver claramente que o Google SQL é mais fácil de ler.

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 2024-08-30

Lembra o LINQ do C#. Sempre que uso SQL, penso que seria melhor se a ordem do SELECT viesse depois de FROM e WHERE....
No começo parece estranho por falta de costume, mas se você ler devagar, o fluxo acaba parecendo bem mais natural.
 
regentag 2024-08-27

Parece que o lado do SQL é mais fácil de ler.
 
leftliber 2024-08-27

Para mim, a parte de SQL é muito mais fácil de ler. Haha. Acho que a maioria de quem começou com SQL deve sentir o mesmo...
 
superwoou 2024-08-28

Para mim também, o que é mais familiar acaba sendo mais fácil de ler.. kkk
 
GN⁺ 2024-08-26
Comentários do Hacker News
  • A sintaxe de pipeline do SQL ficou mais legível
  • Na Google, a sintaxe de pipeline foi útil ao escrever consultas SQL
  • Espera-se que a sintaxe de pipeline do SQL se torne algo generalizado
  • O resultado de converter PDF em HTML no Google AI Studio foi bom
  • Uso SQL há mais de 20 anos, mas ainda tenho dificuldade para expressar certas consultas
  • O projeto open source ZetaSQL, do Google, adicionou documentação sobre a sintaxe de pipeline
  • As reclamações sobre a sintaxe do SQL têm baixa prioridade
    • São necessários recursos como tipos de dados algébricos, lógica booleana de verdade e composição funcional
  • Houve muitas tentativas de reduzir a dificuldade de escrever SQL, mas nenhuma teve sucesso
    • A abordagem dos autores é gradual e adequada para usuários existentes de SQL
  • A sintaxe de pipeline é melhor do que o estado atual
    • Uma sintaxe que modele a execução da consulta como um grafo direcionado de operações seria melhor
      • JOINs podem ser modelados como operações de "referência cruzada" que consomem dois ou mais fluxos de dados e produzem um fluxo de dados
      • CTEs podem ser modeladas como algo que gera vários fluxos de dados
      • CTEs recursivas podem ser modeladas como ciclos no grafo de execução
  • Lembra Elixir
    • Se a sintaxe SQL existente continuar sendo suportada, tudo bem, mas consultas com vários JOINs, subconsultas e agregações podem ficar difíceis de ler
  • Faz lembrar PRQL e SPL do Splunk