Cosas que quiero en un lenguaje de consulta relacional moderno
La sintaxis torpe de SQL, su pobre componibilidad y su comportamiento difícil de depurar están llevando a muchos ingenieros a preguntarse si debería seguir siendo la forma dominante de consultar datos relacionales. Los comentaristas sopesan las ventajas de su ubicuidad y de un ecosistema probado frente a ideas más nuevas como sistemas basados en Datalog, sintaxis en pipeline al estilo PRQL, consultas en vivo/en streaming y enfoques integrados en el lenguaje o basados en IR que compilan a SQL o a un núcleo de menor nivel. Los grandes modelos de lenguaje complican aún más el panorama: hacen que SQL sea más fácil de generar a partir de texto, reduciendo la presión para cambiarlo, pero también bajan la barrera para experimentar con lenguajes de consulta completamente nuevos.
Ergonomía y componibilidad de SQL
- Muchos comentaristas ven SQL como cognitivamente pesado: no componible, difícil de refactorizar y torpe para construir consultas de forma incremental.
- Los joins se describen como una forma “antinatural” de expresar relaciones, especialmente en comparación con la navegación tipo puntero o las APIs estilo grafo.
- Otros se oponen, argumentando que la sintaxis de SQL es simple, ampliamente conocida, y que el temor a SQL es más cultural que técnico.
- Los niveles de aislamiento, el comportamiento de bloqueo y los cambios en los planes del optimizador se consideran puntos críticos importantes que los desarrolladores típicos tienen dificultades para entender.
ORMs, SQL en bruto y herramientas
- Los ORMs se valoran por la seguridad (parametrización contra la inyección SQL) y una ergonomía de nivel superior.
- Los críticos dicen que los ORMs fomentan evitar funciones potentes de SQL (CTEs, funciones de ventana, particionado, procedimientos almacenados) y pueden ocultar trampas transaccionales.
- Algunos abogan por hacer más fácil desplegar SQL en bruto/procedimientos almacenados, tratando la base de datos más como un componente “scriptable”.
- Depurar lógica dividida entre el código de la app y los procedimientos almacenados se describe con frecuencia como doloroso.
LLMs y lenguajes de consulta
- Un hilo argumenta que SQL se volverá como el ensamblador: mayormente generado por herramientas/LLMs, haciendo que las quejas sobre la sintaxis sean menos relevantes.
- Otros responden que los LLMs también pueden aprender y diseñar rápidamente nuevos lenguajes y runtimes, lo que potencialmente reduce la barrera para la experimentación.
- Hay desacuerdo sobre si los LLMs rinden significativamente peor en lenguajes novedosos que en lenguajes con muchos datos como SQL.
Alternativas y experimentos
- Datalog y los sistemas basados en Datalog (p. ej., CodeQL, varios motores de código abierto) se citan repetidamente como más componibles y expresivos.
- Otros esfuerzos mencionados: PRQL, consultas estilo grafo (GraphQL, Cypher), sintaxis de consulta compactas orientadas a LLM, consultas de documentos al estilo Mongo, y bases de datos que exponen un IR para múltiples lenguajes de front-end.
- Algunos comparan SQL desfavorablemente con sistemas más “relacionalmente puros” que ya existen, argumentando que el dominio de SQL es histórico, no técnico.
Mejoras deseadas
- Mejores mensajes de error y diagnósticos para SQL complejo.
- Soporte de primera clase para estructuras anidadas/relacionales en lugar de tablas planas.
- Consultas en vivo/continuas o deltas de streaming en lugar de sondeos repetidos.
- Advertencias de deprecación de columnas, versionado de esquemas y evolución de esquemas más segura.
- Consultas tipadas e integradas en el lenguaje que compilen a un IR relacional compartido, permitiendo que coexistan distintas sintaxis.
Adopción e inercia
- Reemplazar SQL se ve como extremadamente difícil porque:
- La experiencia, las herramientas y el ecosistema están centrados en SQL.
- Los nuevos lenguajes deben ser muchísimo mejores para justificar una migración.
- Algunos concluyen que SQL es “lo peor salvo por todo lo demás que se ha probado”, con muchos intentos que terminan reinsertando SQL o añadiendo compatibilidad con SQL con el tiempo.