La diferencia número uno para mí: si HAVINGse eliminó del lenguaje SQL, la vida continuaría más o menos como antes. Ciertamente, las consultas de una minoría tendrían que reescribirse usando una tabla derivada, CTE, etc., pero como resultado podrían ser más fáciles de entender y mantener. Tal vez el código del optimizador de los proveedores deba reescribirse para tener esto en cuenta, una vez más, una oportunidad de mejora dentro de la industria.
Ahora considere por un momento eliminar WHEREdel lenguaje. Esta vez, la mayoría de las consultas existentes deberían reescribirse sin una construcción alternativa obvia. Los codificadores tendrían que ser creativos, por ejemplo, la unión interna a una tabla que se sabe que contiene exactamente una fila (por ejemplo, DUALen Oracle) usando la ONcláusula para simular la WHEREcláusula anterior . Tales construcciones serían inventadas; sería obvio que faltaba algo en el lenguaje y la situación sería peor como resultado.
TL; DR podríamos perder HAVINGmañana y las cosas no serían peores, posiblemente mejores, pero no se puede decir lo mismo WHERE.
De las respuestas aquí, parece que muchas personas no se dan cuenta de que una HAVINGcláusula puede usarse sin una GROUP BYcláusula. En este caso, la HAVINGcláusula se aplica a toda la expresión de la tabla y requiere que solo aparezcan constantes en la SELECTcláusula. Típicamente la HAVINGcláusula involucrará agregados.
Esto es más útil de lo que parece. Por ejemplo, considere esta consulta para probar si la namecolumna es única para todos los valores en T:
SELECT 1 AS result
FROM T
HAVING COUNT( DISTINCT name ) = COUNT( name );
Solo hay dos resultados posibles: si la HAVINGcláusula es verdadera, el resultado será una sola fila que contenga el valor 1; de lo contrario, el resultado será el conjunto vacío.
HAVINGes un filtro de agregación posterior, mientras queWHEREes un filtro de agregación previa.