Работали ли вы с HAVING в SQL

Что проверяют

Умеете ли вы проверять данные в базе, а не только глазами в интерфейсе. Вопрос про HAVING показывает, дотягиваетесь ли вы до слоя, где живут дубли, потерянные связи и расхождения отчёта с источником.

Как отвечать

Объясните разницу: WHERE фильтрует строки до группировки, HAVING фильтрует группы после неё, поэтому агрегат в WHERE написать нельзя. Дальше сразу к задачам тестировщика, их немного и они повторяются:

• поиск дублей по бизнес-ключу;
• проверка инварианта «не больше одной активной подписки на пользователя»;
• сверка итогов витрины с пересчётом по сырым данным;
• поиск заказов, у которых платежей больше одного.

select lower(email) as mail, count(*) as cnt
from users
group by lower(email)
having count(*) > 1;

Сильный ход: сказать, что такие запросы оформляются как проверки с ожидаемым пустым результатом и живут в наборе тестов, а не в личном файле со сниппетами. Тогда регрессия ловится автоматически.

Упомяните и нормализацию ключа перед группировкой: регистр, лишние пробелы, телефон с разными разделителями. Дубли чаще всего прячутся именно там, и группировка по сырой колонке их не покажет.

Где спотыкаются

Сравнивают только количество строк до и после операции. Число совпало, а содержимое разъехалось: пара строк пропала, пара задвоилась. Проверять надо ключ и значения, а having count(*) > 1 показывает это сразу.

Второе: не различают «нет группы» и «ноль». Если строк по условию нет, группа не появится вовсе, а sum по пустому множеству вернёт NULL, а не ноль. Тест, ожидающий ноль в ячейке, упадёт на ровном месте или пройдёт мимо ошибки.

Третье: запрос без границ периода и часового пояса. Проверка зеленеет днём и краснеет ночью, потому что сутки в базе и сутки в отчёте посчитаны по разным зонам. Отдельная беда, когда тест идёт на общий стенд, где данные правят другие.