Как хранится информация о руководителях в таблице employees?

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

Понимаете ли вы самоссылающуюся таблицу и умеете ли написать к ней запрос. Для тестировщика это классика: следом дают задачу вроде «выведите сотрудников, которые получают больше своего руководителя».

Как отвечать

Руководитель хранится в той же таблице: колонка manager_id ссылается внешним ключом на employee_id этой же таблицы, а у генерального директора в ней NULL. Такая схема называется списком смежности.

Запросы, которые стоит уметь написать:

• сотрудник и его руководитель: self join employees e LEFT JOIN employees m ON e.manager_id = m.employee_id. Именно LEFT, иначе пропадут сотрудники без руководителя;
• зарплата выше, чем у руководителя: тот же join с условием e.salary > m.salary;
• вся ветка подчинённых: рекурсивный CTE, WITH RECURSIVE в PostgreSQL и MySQL 8, в SQL Server то же без слова RECURSIVE, в Oracle ещё встречается CONNECT BY.

Затем покажите взгляд тестировщика, что проверить в данных и в приложении:

• ссылка на несуществующего: внешний ключ должен это запрещать;
• сам себе руководитель: ловится CHECK (manager_id <> employee_id);
• цикл: A подчиняется B, B подчиняется A. Ограничением такое не запретить, нужна проверка в приложении или триггер, а рекурсивный запрос уйдёт в бесконечность или упадёт на лимите глубины;
• удаление руководителя: что происходит с подчинёнными, ON DELETE SET NULL, RESTRICT или переназначение.

Если руководителей может быть несколько (матричная структура), нужна отдельная таблица связей.

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

Пишут INNER JOIN и теряют верхушку иерархии. Проверка «в отчёте все сотрудники» проваливается на директоре.

Предлагают хранить имя руководителя текстом. Однофамильцы, переименования и опечатки ломают связь, а целостность ничем не гарантирована.

Для глубокой иерархии пишут цепочку из пяти self join. Это работает только на фиксированную глубину, а рекурсивный CTE решает задачу для любой.