E se uma instrução SQL retornasse um banco de dados?

Artigo original ↗ Discussão no Hacker News ↗

Uma nova extensão de SQL propõe permitir que uma consulta retorne um conjunto inteiro de tabelas relacionadas — essencialmente um pequeno “sub-banco de dados” normalizado — em vez de uma única tabela de resultado desnormalizada. Os defensores veem benefícios para ORMs, dados hierárquicos, desempenho (menos dados duplicados na rede) e preservação de informações de esquema/chave, aproximando a ideia de GraphQL, Datomic e bancos de dados categoriais. Os críticos respondem que ferramentas existentes (joins, múltiplas consultas, JSON/JSONB, procedures armazenados) já cobrem a maioria dos casos de uso e argumentam que a complexidade adicional e a terminologia nebulosa entre “banco de dados” e “esquema” talvez não justifiquem um novo recurso de linguagem.

Conceito: “SELECT RESULTDB” / Retornando um Resultado Semelhante a um Banco de Dados

  • Proposta: estender o SQL para que uma consulta possa retornar várias tabelas relacionadas (um “subconjunto do banco de dados”) em vez de um único conjunto de resultados desnormalizado.
  • Pense nisso como uma “junção normalizada”: você obtém relações separadas para cada tabela envolvida, com apenas as linhas relevantes, e chaves/relações preservadas.
  • A intenção é reduzir a duplicação de dados em junções e manter mais informações de esquema/chave no resultado.

Motivações e Casos de Uso

  • Desempenho: evitar repetir dados do pai em resultados grandes de junções; menos dados trafegando na rede, especialmente em esquemas pai–filho / snowflake.
  • ORMs: mais fácil popular grafos de objetos (por exemplo, receitas e ingredientes, pedidos e clientes) sem consultas N+1 ou grandes junções desnormalizadas.
  • Latência: uma única ida e volta para buscar várias relações relacionadas em vez de muitas consultas.
  • Consistência: uma única consulta pode fornecer um snapshot de dados relacionados que várias consultas poderiam obter de forma inconsistente.
  • Possível encaixe em bancos de dados de borda / espelhos locais: buscar um “banco de dados parcial” para uso offline ou consultas no lado do cliente.

Críticas e Ceticismo

  • Muitos argumentam que as ferramentas existentes já são suficientes: várias consultas (possivelmente em paralelo), agregações JSON/array, views, procedures armazenados que retornam múltiplos conjuntos de resultados, cursores.
  • Alguns veem resultados de consulta desnormalizados como um recurso: consultas devem moldar os dados no formato desejado, não espelhar o esquema.
  • A preocupação é que construir um “banco de dados de resultado” em memória apenas desloca a complexidade para o cliente, que precisa consultá-lo novamente.
  • Alguns acham que o artigo não entende bem ou deturpa o modelo relacional, ou confunde “relacional” com as limitações do SQL.
  • Outros veem isso como açúcar sintático em torno de empacotar/desempacotar múltiplas relações.

Tecnologias Relacionadas e Trabalhos Anteriores

  • Comparações com GraphQL, JSON:API, suporte SQL a JSON/JSONB, FOR JSON do SQL Server, conjuntos de múltiplos resultados ODBC/MARS, “nested result set” da Akiban.
  • Links para ideias categórico-teóricas de “consultas como morfismos entre bancos de dados” e para sistemas de grafos/Datalog e ideias do tipo Datomic de “banco de dados como valor”.

Perguntas em Aberto e Ambiguidades

  • A semântica exata de chaves, chaves estrangeiras e agregações (por exemplo, SUM, MAX) em um resultado multi-tabela é discutida, mas não totalmente resolvida no tópico.
  • Até que ponto isso traz benefício real em comparação com compressão e padrões atuais é debatido e permanece incerto.