Відмінність номер одне для мене: якщо 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
пункт істинний, то результат з одним рядком, що містить значення 1
, інакше результатом буде порожній набір.
HAVING
це фільтр після агрегації, тоді як фільтрWHERE
перед агрегацією.