Início / dba / Perguntas / 196292
Accepted
Dai
Asked: 2018-01-26 17:35:21 +0800 CST

Algum dialeto SQL permite a sequência lógica de cláusulas SELECT?

  • 772

SELECTno padrão ISO/IEC SQL prescreve a seguinte ordem sintática para as subcláusulas:

SELECT
    projection-expressions
FROM
    sources
WHERE
    predicate-expression
GROUP BY
    key-expression
HAVING
    predicate-expression
ORDER BY
    ordering-expressions

Enquanto a ordem lógica de execução é esta:

FROM
    sources
WHERE
    predicate-expression
GROUP BY
    value-expression
HAVING
    value-expression
SELECT
    projection-expressions
ORDER BY
    ordering-expressions

Para usuários iniciantes de SQL, torna-se surpreendente que uma projeção definida na SELECTcláusula não esteja disponível nas cláusulas WHEREou GROUP BYmesmo que seja declarada primeiro - dado que os programas de computador geralmente seguem a ordem de execução de cima para baixo.

Também é surpreendente que os autores de SQL sejam obrigados a repetir suas expressões em cláusulas SELECT, WHEREe de GROUP BYforma redundante ou usar uma subconsulta que não se presta a uma consulta sucinta. Pelo menos quando o usuário está familiarizado com a ordem real de execução da cláusula, ele sabe por que precisa se repetir, mas isso não impede que seja frustrante.

Este problema e outros problemas relacionados estão documentados neste artigo que encontrei: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of-sql-operations/ e não é surpresa que um controle de qualidade no StackOverflow tem quase 30.000 visualizações: https://stackoverflow.com/questions/3241352/using-an-alias-column-in-the-where-clause-in-postgresql

Isso me fez pensar se alguma implementação de SQL permite essa ordenação mais "lógica" de cláusulas. Observo que o Linq no .NET realmente segue essa ordem, embora eu não o descreva como sendo uma implementação SQL verdadeira, mas, de fato, no Linq o equivalente seria:

source // FROM equivalent
    .Where( predicate-expression )
    .GroupBy( key-expression )
    .Where( predicate-expression ) // HAVING equivalent
    .Select( projection-expression )
    .OrderBy( ordering-expression )

(Também gosto de como o Linq permite adicionar uma Select()projeção em qualquer lugar na sequência de comandos para que você possa usar suas expressões avaliadas sem precisar invocar expressões novamente).

Então, alguma implementação de SQL permite que você expresse consultas em uma estrutura mais lógica?

syntax

1 respostas

  1. Best Answer

    implementações de SQL

    Não, o SQL é padronizado. Não há implementações muito diferentes de um padrão. Esse tipo de derrota o propósito. Sempre houve/há uma briga sobre o cálculo relacional (que o SQL finge ser) versus a abordagem de álgebra relacional. É uma velha discussão,

    Tendo selecionado um modelo para os dados, nosso próximo passo foi selecionar uma linguagem de consulta. Duas famílias de sublinguagens de dados de nível superior para um banco de dados relacional são baseadas, alternativamente, na álgebra relacional (derivada da álgebra de conjuntos) ou no cálculo relacional [Codd, 197lb, 1971c e Date, 1975] (derivado do cálculo de predicados ). Codd [1971c] e Date [1975] compararam esses dois e descobriram que o cálculo relacional é superior, particularmente para uso como linguagem-alvo para um sistema de linguagem natural. A principal razão para a escolha do cálculo relacional como língua-alvo foi que o cálculo não é procedimental; ou seja, uma consulta no cálculo relacional traz poucas informações sobre como proceder na busca na base de dados. A álgebra relacional é mais procedimental, o que dificulta um pouco a construção automática de uma consulta por um sistema de linguagem natural. -Implementação de uma Linguagem de Consulta baseada no Cálculo Relacional 1970

    E, novamente do próprio Codd,

    No início do desenvolvimento do modelo relacional (1969-1972), inventei duas linguagens para lidar com relações: uma de natureza algébrica e outra baseada na lógica de predicados de primeira ordem [Codd 1971a]. Provei então que as duas linguagens tinham poder expressivo igual [Codd 1971d], mas indiquei que a linguagem baseada em lógica seria mais otimizável (assumindo que o rastreamento de fluxo não foi tentado) e mais fácil de usar como uma interface para software inferencial em cima de o SGBD. - Codd 1990, o modelo relacional para gerenciamento de banco de dados versão 2

    Há certamente uma tonelada de implementações para ambas as abordagens. Dito isto, o SQL como uma implementação é bastante fixo na abordagem de cálculo.

    Problemas de LINQ

    Esses problemas nunca desapareceram com a abordagem algébrica, por exemplo, deste blog, .

    context.Cars
  .OrderBy(x => x.Id)
  .Skip(50000)
  .Take(1000)
  .ToList();

    Requer otimização manual como,

    context.Cars
    .Where(x => context.Cars
        .OrderBy(y => y.Id)
        .Select(y => y.Id)
        .Skip(50000)
        .Take(1000)
        .Contains(x.Id)
    )
    .ToList();

    Se você tiver várias relações diferentes com diferentes características de desempenho (índices, a maioria dos quais são implementados como indiretos e abstratos) e estatísticas, é difícil escrever uma lógica de conjunto procedural que funcione com eficiência.

    • 9

relate perguntas