SQL es azúcar sintáctico para el álgebra relacional

Visión general de SQL

• Muy usado y potente, pero muchos consideran que su sintaxis es desordenada, inconsistente y “al revés”, especialmente el orden SELECT antes de FROM y las extrañas reglas de ámbito.
• Otros lo encuentran razonablemente fácil de aprender, expresivo y preferible a las sintaxis de consulta basadas en JSON o propietarias; para muchos, los problemas provienen más del mal diseño de esquemas y del mal uso que de SQL en sí.
• Comparación con C: conviene conocerlo a fondo, pero algunos prefieren abstracciones “gestionadas”; los críticos responden que los ORM tienen fugas y a menudo carecen de potencia.

Sintaxis, ergonomía y herramientas

• Quejas: orden de análisis no intuitivo, dificultad para leer consultas anidadas complejas, autocompletado difícil porque las fuentes vienen después de las proyecciones, y comandos peligrosos como DELETE FROM sin barreras de protección.
• Mitigaciones: uso de CTE, funciones que devuelven tablas, tablas temporales, transacciones y salvaguardas del cliente (WHERE obligatorio para borrados, banderas especiales).
• El formato, los comentarios y los diagramas ER se consideran cruciales para mantener SQL complejo.

Álgebra relacional, teoría y el estándar

• Muchos están de acuerdo en que SQL no es un azúcar sintáctico limpio sobre el álgebra relacional: multiconjuntos frente a conjuntos, semántica de NULL, ordenación y muchos “adornos no relacionales”.
• Las referencias al modelo relacional de Codd, cálculo de predicados, Datalog, el IR de MonetDB y el “Third Manifesto” destacan el deseo de lenguajes más cercanos a la teoría relacional formal.
• El estándar SQL es visto por algunos como demasiado complejo y, en la práctica, como un foso que eleva la barrera de entrada para nuevas implementaciones de bases de datos.

Alternativas y lenguajes relacionados

• Alternativas o complementos mencionados: PRQL, XTQL, compresiones al estilo LINQ, Malloy, CozoDB, bibliotecas de dataframes (Pandas, Polars, Ibis) y lenguajes de estilo D (aunque no hay una implementación popular).
• Estos suelen mejorar la componibilidad, la lectura de izquierda a derecha y la integración con lenguajes anfitriones, pero normalmente carecen de soporte completo para DML, funciones específicas del proveedor o madurez.

Aprendizaje, pedagogía y práctica

• Varios cuentan que tardaron años en “entender de verdad” SQL, a menudo desencadenado por trabajo a gran escala o con mucha carga de rendimiento.
• La educación formal en bases de datos es desigual; algunos critican la enseñanza muy teórica (incluidos algunos textos sobre teoría relacional), mientras que otros elogian introducciones accesibles y libros prácticos de diseño.
• Tema fuerte: entender la teoría relacional y un buen diseño de esquemas mejora drásticamente SQL, pero las asperezas de SQL siguen limitando lo que motores RDBMS bien diseñados podrían exponer.