Разница номер один для меня: если бы 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
, в противном случае результатом будет пустой набор.