Diferença número um para mim: se HAVING
fosse removido da linguagem SQL, a vida continuaria mais ou menos como antes. Certamente, as consultas de uma minoria precisariam ser reescritas usando uma tabela derivada, CTE, etc., mas seriam mais fáceis de entender e manter como resultado. Talvez o código otimizador dos fornecedores precise ser reescrito para dar conta disso, novamente uma oportunidade de aprimoramento no setor.
Agora considere por um momento remover WHERE
do idioma. Dessa vez, a maioria das consultas existentes precisaria ser reescrita sem uma construção alternativa óbvia. Os codificadores precisariam ser criativos, por exemplo, junção interna a uma tabela conhecida por conter exatamente uma linha (por exemplo, DUAL
no Oracle) usando a ON
cláusula para simular a WHERE
cláusula anterior . Tais construções seriam inventadas; seria óbvio que havia algo faltando no idioma e a situação seria pior como resultado.
TL; DR, poderíamos perder HAVING
amanhã e as coisas não seriam piores, possivelmente melhores, mas não se pode dizer o mesmo WHERE
.
A partir das respostas aqui, parece que muitas pessoas não percebem que uma HAVING
cláusula pode ser usada sem uma GROUP BY
cláusula. Nesse caso, a HAVING
cláusula é aplicada a toda a expressão da tabela e requer que apenas constantes apareçam na SELECT
cláusula. Normalmente, a HAVING
cláusula envolve agregados.
Isso é mais útil do que parece. Por exemplo, considere esta consulta para testar se a name
coluna é exclusiva para todos os valores em T
:
SELECT 1 AS result
FROM T
HAVING COUNT( DISTINCT name ) = COUNT( name );
Existem apenas dois resultados possíveis: se a HAVING
cláusula for verdadeira, o resultado será uma única linha contendo o valor 1
; caso contrário, o resultado será o conjunto vazio.
HAVING
é um filtro de pós-agregação, enquanto queWHERE
é um filtro de pré-agregação.