Разница в номер один для меня: если бы он HAVINGбыл удален из языка SQL, жизнь продолжалась бы более или менее так же, как и раньше. Конечно, запросы меньшинства должны были бы быть переписаны с использованием производной таблицы, CTE и т. Д., Но в результате их было бы легче понять и поддерживать. Может быть, код оптимизатора продавцов нужно будет переписать, чтобы учесть это, опять же возможность для улучшения в отрасли.
Теперь рассмотрим на минуту удаление WHEREиз языка. На этот раз большинство существующих запросов нужно было бы переписать без очевидной альтернативной конструкции. Кодировщики должны проявить творческий подход, например, внутреннее объединение с таблицей, которая, как известно, содержит ровно одну строку (например, DUALв Oracle), используя ONпредложение для имитации предыдущегоWHERE предложения. Такие конструкции будут изобретены; было бы очевидно, что в языке чего-то не хватает, и в результате ситуация будет еще хуже.
TL; DR, мы можем проиграть HAVINGзавтра, и все будет не хуже, возможно, лучше, но этого нельзя сказать WHERE.
Из ответов здесь, кажется, что многие люди не понимают, что HAVINGпункт может быть использован без GROUP BYпункта. В этом случае HAVINGпредложение применяется ко всему табличному выражению и требует, чтобы в предложении присутствовали только константы SELECT. Как правило, HAVINGпункт будет включать в себя агрегаты.
Это полезнее, чем кажется. Например, рассмотрим этот запрос, чтобы проверить, nameявляется ли столбец уникальным для всех значений в T:
SELECT 1 AS result
FROM T
HAVING COUNT( DISTINCT name ) = COUNT( name );
Возможны только два результата: если HAVINGпредложение имеет значение true, то результатом будет одна строка, содержащая значение 1, в противном случае результатом будет пустой набор.
HAVINGфильтр постагрегации , тогда как фильтр предагрегированияWHERE.