Repensando a Programação de Bancos de Dados

Artigo original ↗ Discussão no Hacker News ↗

Uma nova linguagem funcional, fechada e inspirada em Elm, que compila para SQL em PostgreSQL e SQLite, está reacendendo debates de longa data sobre a melhor forma de programar bancos de dados relacionais. Os defensores gostam de suas consultas composáveis e fortemente tipadas, da segurança de tipos de ponta a ponta entre banco e frontend, e de recursos como tipos soma e segurança obrigatória em nível de linha, enquanto os críticos veem apenas mais uma abstração no estilo ORM que obscurece o SQL, fica atrás dos recursos do banco e corre o risco de acoplar os dados demais a uma única linguagem e fornecedor. Muitos também questionam a licença por assinatura e a governança por um único fornecedor, argumentando que a maturidade, o ecossistema e o alinhamento do SQL com o modelo relacional ainda superam ganhos ergonômicos incrementais de novas camadas de consulta.

Recepção geral

  • Muitos acham a nova linguagem de consulta funcional esteticamente agradável e conceitualmente empolgante, especialmente fãs de programação funcional e de design no estilo Elm.
  • Outros a veem como uma forma de transformar o SQL conciso em código mais verboso e menos legível, e duvidam que ofereça benefício suficiente em relação ao SQL puro ou a ferramentas existentes.
  • Vários comentam que mais uma “substituição do SQL” provavelmente não conseguirá ampla adoção, dada a maturidade e o ecossistema do SQL.

SQL vs. linguagem de consulta funcional

  • Os defensores argumentam que o SQL é desajeitado, antigo, baseado em strings e difícil de compor ou analisar estaticamente; eles querem pipelines, composição no estilo map/filter e verificação de tipos de ponta a ponta.
  • Os defensores do SQL enfatizam sua base matemática (álgebra relacional), maturidade, recursos poderosos (CTEs, funções de janela) e onipresença, incluindo acessibilidade para não programadores.
  • Alguns observam o desvio do SQL em relação à teoria relacional pura (semântica de multiconjuntos, NULLs), mas ainda o consideram a ferramenta certa para armazenamento e consulta de dados.

ORMs, gestão de esquema e expressividade

  • Há debate sobre se isso é “apenas um ORM disfarçado”. Do ponto de vista do usuário, muitos dizem que ele se comporta como um ORM, apesar das alegações de marketing.
  • Críticos de esquema-em-código no estilo ORM argumentam que essas camadas ficam atrás dos recursos do banco (particionamento, compressão, restrições avançadas) e, no fim, obrigam a voltar ao SQL.
  • Outros preferem abordagens que tratam o SQL como a fonte da verdade e geram bindings tipados a partir dele.

Segurança de tipos e integração frontend–backend

  • Os proponentes destacam a segurança de tipos de ponta a ponta, do banco ao backend e ao frontend, incluindo tipos soma e pipelines reutilizáveis, como um grande diferencial.
  • Os céticos contra-argumentam que o próprio SQL é fortemente tipado (exceto em mecanismos como SQLite) e que a segurança de tipos entre camadas também pode ser obtida via geração de código e mecanismos de “describe”.

Propriedade do banco, arquitetura e longevidade

  • Alguns desconfiam de uma linguagem “ser dona” do banco, especialmente com codificações personalizadas (por exemplo, para tipos soma) que complicam a interoperabilidade e o acesso aos dados no longo prazo.
  • Vários enfatizam que bancos de dados e esquemas SQL frequentemente sobrevivem a qualquer aplicativo ou linguagem específica; preferem que o banco seja o centro estável, e não um alvo de compilação.
  • Há ceticismo de que vincular a representação dos dados de forma tão rígida a uma linguagem fechada e de nicho seja sensato para sistemas de longa duração.

Licenciamento, modelo de financiamento e confiança

  • A licença fechada e baseada em assinatura gera preocupação significativa. Uma cláusula citada sugere que os usuários podem perder acesso aos dados quando a assinatura expira, algo que muitos veem como inaceitável para sistemas críticos.
  • Experiências passadas com projetos semelhantes levaram vários comentaristas a se preocupar com o “bus factor” e a manutenção de longo prazo; a dependência de uma pequena equipe é vista como arriscada.
  • Alguns acolhem a experimentação com novos modelos de financiamento para um desenvolvimento sustentável, mas ainda assim não adotariam isso em projetos profissionais ou mesmo pessoais devido ao risco.

Alternativas e trabalhos anteriores

  • Os comentaristas apontam iniciativas anteriores com ideias semelhantes: LINQ, bibliotecas Haskell como Selda, sistemas baseados em Datalog, geradores de código SQL (por exemplo, sqlc, Ormin) e outras “linguagens de programação de banco de dados”.
  • Profissionais experientes argumentam que décadas de tentativas de linguagens integradas a bancos e ORMs, em grande parte, não superaram “usar apenas SQL + um driver”, especialmente em desempenho e transparência.

Usabilidade, documentação e perguntas em aberto

  • As pessoas querem ver exemplos complexos de joins entre múltiplas tabelas e como agrupamentos/agregações são expressos, observando que exemplos simples não convencem.
  • Alguns ficam intrigados com recursos como segurança obrigatória em nível de linha e tipos de dados algébricos, mas consideram a sintaxe difícil de ler rapidamente.
  • A documentação é descrita como superficial (por exemplo, palavras-chave mencionadas, mas não totalmente explicadas), o que dificulta avaliar o sistema em profundidade.
  • Continua pouco claro quão bem a linguagem expõe os recursos completos de PostgreSQL/SQLite e como migrações e evolução de esquema (especialmente para tipos avançados) são tratadas na prática.