Coisas que quero numa linguagem de consulta relacional moderna
A sintaxe desajeitada do SQL, sua pouca composabilidade e o comportamento difícil de depurar levam muitos engenheiros a questionar se ele deve continuar sendo a forma dominante de consultar dados relacionais. Os comentaristas ponderam os benefícios de sua ubiquidade e de um ecossistema testado em batalha contra ideias mais novas, como sistemas baseados em Datalog, sintaxe em pipeline no estilo PRQL, consultas ao vivo/em streaming e abordagens integradas à linguagem ou baseadas em IR que compilam para SQL ou para um núcleo de nível mais baixo. Os modelos de linguagem de grande porte complicam ainda mais o cenário: eles tornam o SQL mais fácil de gerar a partir de texto, reduzindo a pressão por mudança, mas também diminuem a barreira para experimentar linguagens de consulta totalmente novas.
Ergonomia e composabilidade do SQL
- Muitos comentaristas veem SQL como cognitivamente pesado: não composável, difícil de refatorar e desajeitado para construir consultas incrementais.
- Os joins são descritos como uma forma “não natural” de expressar relações, especialmente em comparação com navegação semelhante a ponteiros ou APIs no estilo de grafos.
- Outros rebatem, argumentando que a sintaxe do SQL é simples, amplamente conhecida e que o medo de SQL é mais cultural do que técnico.
- Níveis de isolamento, comportamento de locking e mudanças nos planos do otimizador são vistos como grandes pontos de dor que desenvolvedores comuns têm dificuldade em entender.
ORMs, SQL bruto e ferramentas
- ORMs são valorizados por segurança (parametrização contra SQL injection) e por uma ergonomia de nível mais alto.
- Críticos dizem que ORMs incentivam evitar recursos poderosos do SQL (CTEs, window functions, partitioning, stored procedures) e podem esconder armadilhas transacionais.
- Alguns defendem tornar o SQL bruto/stored procedures mais fáceis de implantar, tratando o banco de dados mais como um componente “scriptável”.
- Depurar lógica dividida entre código da aplicação e stored procedures é frequentemente descrito como doloroso.
LLMs e linguagens de consulta
- Um fio argumenta que SQL se tornará como assembly: em grande parte gerado por ferramentas/LLMs, tornando reclamações sobre a sintaxe menos relevantes.
- Outros contrapõem que LLMs também podem aprender e projetar rapidamente novas linguagens e runtimes, potencialmente reduzindo a barreira para experimentação.
- Há discordância sobre se LLMs têm desempenho significativamente pior em linguagens novas em comparação com linguagens de alto volume de dados como SQL.
Alternativas e experimentos
- Datalog e sistemas baseados em Datalog (por exemplo, CodeQL, vários motores open-source) são citados repetidamente como mais composáveis e expressivos.
- Outros esforços mencionados: PRQL, consultas no estilo de grafos (GraphQL, Cypher), sintaxes compactas orientadas a LLMs, consultas de documentos no estilo Mongo e bancos de dados expondo um IR para múltiplas linguagens de front-end.
- Alguns comparam o SQL desfavoravelmente com sistemas mais “relacionalmente puros” que já existem, argumentando que a dominância do SQL é histórica, não técnica.
Melhorias desejadas
- Mensagens de erro e diagnósticos melhores para SQL complexo.
- Suporte de primeira classe para estruturas aninhadas/relacionais em vez de tabelas planas.
- Consultas ao vivo/contínuas ou deltas em streaming em vez de polling repetido.
- Avisos de depreciação de colunas, versionamento de schema e evolução de schema mais segura.
- Consultas tipadas e integradas à linguagem que compilem para um IR relacional compartilhado, permitindo que sintaxes diferentes coexistam.
Adoção e inércia
- Substituir SQL é visto como extremamente difícil porque:
- Expertise, ferramentas e ecossistema são todos centrados em SQL.
- Novas linguagens precisam ser vastamente melhores para justificar a migração.
- Alguns concluem que SQL é “o pior, exceto por todos os outros tentados”, com muitas tentativas acabando por re-embutir SQL ou adicionar compatibilidade com SQL ao longo do tempo.