Как сделать запрос для суммирования зарплат внутри отделов?

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

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

Как отвечать

Базовый запрос строится на агрегатной функции и группировке: SELECT department_id, SUM(salary) AS total FROM employees GROUP BY department_id;. Дальше покажите, что понимаете детали:

• правило группировки: каждая колонка в SELECT либо стоит в GROUP BY, либо обёрнута в агрегат. Иначе PostgreSQL выдаст ошибку, а MySQL с отключённым ONLY_FULL_GROUP_BY вернёт произвольное значение;
• WHERE и HAVING: WHERE фильтрует строки до группировки, HAVING фильтрует уже готовые группы, например HAVING SUM(salary) > 1000000;
• название отдела: нужен JOIN departments d ON d.id = e.department_id и группировка по d.id, d.name;
• пустые отделы: при LEFT JOIN от таблицы departments отдел без сотрудников попадёт в выборку, но сумма у него будет NULL, её закрывают через COALESCE(SUM(e.salary), 0);
• NULL в зарплате: SUM такие строки просто пропускает, а COUNT(salary) и COUNT(*) при этом разойдутся.

Для тестировщика хорошо добавить, зачем это нужно: сверить сумму в отчёте или на дашборде с тем, что лежит в базе, найти сотрудников без отдела (WHERE department_id IS NULL), проверить, что после правки данных в интерфейсе итог пересчитался. Если сумму по отделу нужно показать рядом с каждым сотрудником, упомяните оконную функцию SUM(salary) OVER (PARTITION BY department_id).

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

Добавляют в SELECT имя сотрудника или отдела, не включив его в GROUP BY, и не могут объяснить, почему запрос падает.

Пишут условие по сумме в WHERE. Агрегат там использовать нельзя, для этого и существует HAVING.

Делают INNER JOIN и не замечают, что отделы без сотрудников выпали из результата. В тестировании это ровно тот случай, который и надо было поймать.