¿Y si una sentencia SQL devolviera una base de datos?

Artículo original ↗ Discusión en Hacker News ↗

Una nueva extensión de SQL propone permitir que una consulta devuelva un conjunto completo de tablas relacionadas —esencialmente una pequeña “sub-base de datos” normalizada— en lugar de una sola tabla de resultados desnormalizada. Quienes la apoyan ven ventajas para ORMs, datos jerárquicos, rendimiento (menos datos duplicados en tránsito) y preservación de información de esquema/claves, y la relacionan con ideas de GraphQL, Datomic y bases de datos desde la teoría de categorías. Quienes la critican responden que las herramientas existentes (joins, varias consultas, JSON/JSONB, procedimientos almacenados) ya cubren la mayoría de los casos de uso, y sostienen que la complejidad añadida y la terminología imprecisa sobre “base de datos” frente a “esquema” quizá no justifiquen una nueva característica del lenguaje.

Concepto: “SELECT RESULTDB” / Devolver un resultado similar a una base de datos

  • Propuesta: extender SQL para que una consulta pueda devolver varias tablas relacionadas (un “subconjunto de la base de datos”) en lugar de un único conjunto de resultados desnormalizado.
  • Piensa en ello como una “unión normalizada”: obtienes relaciones separadas para cada tabla implicada, con solo las filas relevantes, y con claves/relaciones preservadas.
  • La intención es reducir la duplicación de datos en las uniones y mantener más información de esquema/claves en el resultado.

Motivaciones y casos de uso

  • Rendimiento: evitar repetir datos del padre en grandes resultados de joins; menos datos en tránsito, especialmente en esquemas padre-hijo / snowflake.
  • ORMs: más fácil hidratar grafos de objetos (por ejemplo, recetas e ingredientes, pedidos y clientes) sin consultas N+1 ni enormes joins desnormalizados.
  • Latencia: un solo viaje de ida y vuelta para obtener varias relaciones relacionadas en lugar de muchas consultas.
  • Consistencia: una única consulta puede proporcionar una instantánea de datos relacionados que varias consultas podrían obtener de forma inconsistente.
  • Posible encaje con bases de datos edge / espejos locales: obtener una “base de datos parcial” para consultas sin conexión o del lado del cliente.

Críticas y escepticismo

  • Muchos sostienen que las herramientas existentes bastan: varias consultas (posiblemente en paralelo), agregados JSON/array, vistas, procedimientos almacenados que devuelven múltiples conjuntos de resultados, cursores.
  • Algunos ven los resultados de consulta desnormalizados como una característica: las consultas deben dar forma a los datos al formato deseado, no reflejar el esquema.
  • Preocupa que construir una “base de datos de resultados” en memoria solo traslade la complejidad al cliente, que luego debe consultarla de nuevo.
  • Algunos sienten que el artículo malinterpreta o tergiversa el modelo relacional, o confunde “relacional” con las limitaciones de SQL.
  • Otros lo ven como azúcar sintáctico para empaquetar/desempaquetar varias relaciones.

Tecnologías relacionadas y trabajos previos

  • Comparaciones con GraphQL, JSON:API, soporte JSON/JSONB de SQL, FOR JSON de SQL Server, conjuntos de múltiples resultados ODBC/MARS, el “nested result set” de Akiban.
  • Enlaces a ideas de teoría de categorías sobre “consultas como morfismos entre bases de datos” y a sistemas de grafos/Datalog e ideas tipo Datomic de “la base de datos como valor”.

Preguntas abiertas y ambigüedades

  • En el hilo se discuten, pero no quedan totalmente resueltas, las semánticas exactas de claves, claves ajenas y agregados (por ejemplo, SUM, MAX) en un resultado de varias tablas.
  • Se debate cuánto beneficio real ofrece frente a la compresión y los patrones actuales, y sigue sin estar claro.