Não deveria FROM vir antes de SELECT em SQL? (2011)

Artigo original ↗ Discussão no Hacker News ↗

A questão de se o SQL deveria colocar `FROM` antes de `SELECT` toca em perguntas mais profundas sobre como linguagens de consulta equilibram legibilidade humana, semântica de execução e suporte de ferramentas. Comentadores observam que a sintaxe atual, semelhante ao inglês, `SELECT ... FROM ...`, dificulta recursos como autocompletar e obscurece a ordem lógica de execução, enquanto alternativas como LINQ, Kusto, PRQL e as extensões do DuckDB mostram que formas com `FROM` primeiro ou em estilo pipeline podem ser mais ergonômicas. Outros argumentam que a idade do SQL, o lock-in do ecossistema e seu objetivo original de ser compreensível para não engenheiros tornam improváveis mudanças radicais de sintaxe, sugerindo que ferramentas melhores ou DSLs complementares são caminhos mais realistas para avançar.

Ordenação de FROM vs SELECT

  • Muitos argumentam que FROM … SELECT … combina melhor com a forma como as pessoas pensam: definir a(s) fonte(s) de dados, depois filtrar/agrupar, e então projetar colunas.
  • Os defensores dizem que isso espelha a forma como as consultas são executadas e tornaria arquivos SQL grandes e complexos mais fáceis de gerenciar e de modelar mentalmente.
  • Outros defendem SELECT … FROM … porque ele começa com o “comando” (select/insert/update/delete), correspondendo à forma como as instruções são classificadas e examinadas em arquivos.
  • A semelhança com o inglês é citada nos dois sentidos: consultas simples leem naturalmente como “select X from Y”, mas instruções mais complexas, com múltiplas ações, talvez fiquem melhores com from primeiro.

Ferramentas, autocompletar e UX de IDE

  • Uma reclamação recorrente: com SELECT primeiro, as IDEs não conseguem oferecer conclusão de colunas até que FROM seja লেখা.
  • Sintaxes FROM-first (LINQ, Kusto/KQL, PRQL, o modo opcional FROM-first do DuckDB, NRQL, ABAP OpenSQL) são elogiadas por permitir melhor intellisense e consultas passo a passo, compostas.
  • Alguns acham que IDEs inteligentes poderiam contornar o SQL atual; outros dizem que o suporte no nível da linguagem ainda é um grande ganho ergonômico.

Ordem de execução vs ordem da sintaxe

  • Vários comentários contrastam a ordem lexical do SQL (SELECT → FROM → WHERE → …) com sua ordem “lógica” de processamento (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY).
  • Esse desencontro é visto como um problema de ensino e de modelo mental, especialmente para iniciantes que esperam que cláusulas anteriores “vejam” cláusulas posteriores.

Segurança e sintaxe de UPDATE

  • UPDATE … SET … WHERE … alarma muita gente porque SET vem antes de WHERE; as pessoas temem omitir acidentalmente o WHERE.
  • Mitigações comuns: escrever o WHERE primeiro, prototipar como SELECT antes de converter para UPDATE, e usar transações explícitas (BEGIN/ROLLBACK, ferramentas que alertam sobre updates sem WHERE).

Objetivos de design, semelhança com o inglês e alternativas

  • O SQL é descrito como antigo, influenciado pelo inglês e projetado para usuários não técnicos; suas peculiaridades persistem por efeitos de rede.
  • Vários comentários sugerem que SQL é “bom o suficiente”, mas confuso para composição, defendendo linguagens de consulta especializadas ou DSLs que compilam para SQL (PRQL, SaneQL, HoneySQL, sistemas parecidos com Datalog, sintaxe no estilo QUEL).
  • Alguns argumentam que os bancos deveriam expor SQL para humanos e uma API separada, mais estruturada, para máquinas.