La diferencia número uno para mí: si HAVING
se 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 WHERE
del 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, DUAL
en Oracle) usando la ON
cláusula para simular la WHERE
clá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 HAVING
mañ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 HAVING
cláusula puede usarse sin una GROUP BY
cláusula. En este caso, la HAVING
cláusula se aplica a toda la expresión de la tabla y requiere que solo aparezcan constantes en la SELECT
cláusula. Típicamente la HAVING
cláusula involucrará agregados.
Esto es más útil de lo que parece. Por ejemplo, considere esta consulta para probar si la name
columna 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 HAVING
cláusula es verdadera, el resultado será una sola fila que contenga el valor 1
; de lo contrario, el resultado será el conjunto vacío.
HAVING
es un filtro de agregación posterior, mientras queWHERE
es un filtro de agregación previa.