Diferença número um para mim: se HAVINGfosse 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 WHEREdo 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, DUALno Oracle) usando a ONcláusula para simular a WHEREclá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 HAVINGamanhã 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 HAVINGcláusula pode ser usada sem uma GROUP BYcláusula. Nesse caso, a HAVINGcláusula é aplicada a toda a expressão da tabela e requer que apenas constantes apareçam na SELECTcláusula. Normalmente, a HAVINGcláusula envolve agregados.
Isso é mais útil do que parece. Por exemplo, considere esta consulta para testar se a namecoluna é 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 HAVINGclá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.