Какой опыт работы с базами данных, включая JOIN, подзапросы и оконные функции

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

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

Как отвечать

Покажите SQL как рабочий инструмент проверки:

• поиск «сирот»: LEFT JOIN users u ON ... и условие WHERE u.id IS NULL находят заказы, у которых нет пользователя. Так проверяют целостность после удаления или миграции;
• дубли: GROUP BY email HAVING COUNT(*) > 1 или ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at), чтобы увидеть, какая запись лишняя;
• сверка с интерфейсом: сумма корзины или остаток на счёте пересчитываются через SUM и сравниваются с тем, что показал экран или вернул API;
• подзапросы: «пользователи с заказами выше среднего» через подзапрос с AVG, проверка наличия связанной записи через EXISTS;
• оконные функции: LAG() для проверки, что статусы заказа менялись в допустимом порядке, SUM() OVER (PARTITION BY user_id ORDER BY created_at) для накопительного баланса.

Расскажите, где SQL встроен в вашу работу: подготовка тестовых данных, проверки после автотеста (например, в фикстуре pytest), разбор бага, когда на экране одно, а в базе другое. Лучший пример тот, где запрос нашёл дефект, которого интерфейс не показывал.

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

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

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

Путают COUNT(*) и COUNT(column) после LEFT JOIN: первый считает и строки с NULL, поэтому у пользователя без заказов получается один заказ.

Правят данные на общем стенде через UPDATE без WHERE или без предварительного SELECT с тем же условием и ломают тесты всей команде.