Разница в номер один для меня: если бы он 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
.