La différence numéro un pour moi: si elle HAVING
était supprimée du langage SQL, la vie continuerait plus ou moins comme avant. Certes, une requête minoritaire devrait être réécrite à l'aide d'une table dérivée, CTE, etc., mais il serait sans doute plus facile à comprendre et à maintenir en conséquence. Peut-être que le code d'optimisation des fournisseurs devrait être réécrit pour en tenir compte, encore une fois une opportunité d'amélioration au sein de l'industrie.
Considérons maintenant un instant la suppression WHERE
de la langue. Cette fois, la majorité des requêtes existantes devraient être réécrites sans construction alternative évidente. Les codeurs devraient faire preuve de créativité, par exemple une jointure interne à une table connue pour contenir exactement une ligne (par exemple DUAL
dans Oracle) en utilisant la ON
clause pour simuler la WHERE
clause précédente . De telles constructions seraient artificielles; il serait évident qu'il manquait quelque chose dans la langue et la situation serait pire en conséquence.
TL; DR nous pourrions perdre HAVING
demain et les choses ne seraient pas pires, peut-être mieux, mais on ne peut pas en dire autant WHERE
.
D'après les réponses ici, il semble que beaucoup de gens ne réalisent pas qu'une HAVING
clause peut être utilisée sans GROUP BY
clause. Dans ce cas, la HAVING
clause est appliquée à l'expression de table entière et requiert que seules les constantes apparaissent dans la SELECT
clause. En règle générale, la HAVING
clause impliquera des agrégats.
C'est plus utile qu'il n'y paraît. Par exemple, considérez cette requête pour tester si la name
colonne est unique pour toutes les valeurs dans T
:
SELECT 1 AS result
FROM T
HAVING COUNT( DISTINCT name ) = COUNT( name );
Il n'y a que deux résultats possibles: si la HAVING
clause est vraie, le résultat sera une seule ligne contenant la valeur 1
, sinon le résultat sera l'ensemble vide.
HAVING
s'agit d'un filtre de post-agrégation, alors qu'ilWHERE
s'agit d'un filtre de pré-agrégation.