¿No debería ir FROM antes de SELECT en SQL? (2011)

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

Que SQL ponga `FROM` antes de `SELECT` toca cuestiones más profundas sobre cómo los lenguajes de consulta equilibran la legibilidad humana, la semántica de ejecución y el soporte de herramientas. Quienes comentan señalan que la sintaxis actual, similar al inglés, `SELECT ... FROM ...`, dificulta funciones como el autocompletado y oculta el orden lógico de ejecución, mientras que alternativas como LINQ, Kusto, PRQL y las extensiones de DuckDB muestran que las formas `FROM`-first o de estilo pipeline pueden ser más ergonómicas. Otros sostienen que la antigüedad de SQL, el bloqueo del ecosistema y su objetivo original de ser comprensible para personas no técnicas hacen poco probable un cambio radical de sintaxis, por lo que herramientas mejores o DSL complementarios parecen vías más realistas.

Orden de FROM frente a SELECT

  • Muchos sostienen que FROM … SELECT … se ajusta mejor a cómo piensa la gente: definir la(s) fuente(s) de datos, luego filtrar/agrupar y después proyectar columnas.
  • Quienes lo defienden dicen que esto refleja cómo se ejecutan las consultas y que haría que los archivos SQL grandes y complejos fueran más fáciles de gestionar y modelar mentalmente.
  • Otros defienden SELECT … FROM … porque empieza con el “comando” (select/insert/update/delete), lo que encaja con cómo se clasifican y se recorren las sentencias en los archivos.
  • La similitud con el inglés se cita en ambos sentidos: las consultas simples se leen de forma natural como “select X from Y”, pero las sentencias más complejas y de múltiples acciones, en teoría, se leen mejor con from primero.

Herramientas, autocompletado y UX del IDE

  • Una queja recurrente: con SELECT primero, los IDE no pueden ofrecer completado de columnas hasta que se escribe FROM.
  • Las sintaxis FROM-primero (LINQ, Kusto/KQL, PRQL, el modo opcional FROM-first de DuckDB, NRQL, ABAP OpenSQL) reciben elogios por permitir un mejor intellisense y consultas paso a paso y componibles.
  • Algunos creen que los IDE inteligentes podrían solventar el SQL actual; otros dicen que el soporte a nivel de lenguaje sigue siendo una gran mejora de ergonomía.

Orden de ejecución frente a orden sintáctico

  • Varias publicaciones contrastan el orden léxico de SQL (SELECT → FROM → WHERE → …) con su orden de procesamiento “lógico” (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY).
  • Esta discrepancia se ve como un problema de enseñanza y de modelo mental, especialmente para quienes empiezan y esperan que las cláusulas anteriores “vean” las posteriores.

Seguridad y sintaxis de UPDATE

  • UPDATE … SET … WHERE … alarma a muchas personas porque SET precede a WHERE; temen omitir accidentalmente el WHERE.
  • Mitigaciones comunes: escribir primero el WHERE, prototipar como SELECT antes de convertirlo en UPDATE y usar transacciones explícitas (BEGIN/ROLLBACK, herramientas que advierten sobre actualizaciones sin WHERE).

Objetivos de diseño, parecido al inglés y alternativas

  • SQL se describe como antiguo, influido por el inglés y diseñado para usuarios no técnicos; sus rarezas persisten por los efectos de red.
  • Varias publicaciones sugieren que SQL es “lo bastante bueno” pero desordenado para la composición, y abogan por lenguajes de consulta especializados o DSL que compilen a SQL (PRQL, SaneQL, HoneySQL, sistemas tipo Datalog, sintaxis al estilo QUEL).
  • Algunos argumentan que las bases de datos deberían exponer SQL para humanos y una API separada, más estructurada, para máquinas.