В OpenAI завезли Study & Learn. Я решил попробовать на o3 модели, можно ли помокаться по SQL
Промпт на входе.
I want to test my knowledge on SQL, can you prepare test questions for me and work on them with commentary?
Experience level - advanced
Focus area - should cover all aspects
Format & length - mix, it should cover standard 30 minute interview
Получился план из 6 задач
===
1. Окна: вторая по выручке дата
Таблица sales(salesperson_id, sale_date, amount). Для каждого продавца вернуть дату второй по сумме выручки за день.
Классическая задача на оконки с агрегатными функциям. GROUP BY, SUM(amount), ROW_NUMBER(), фильтр rown = 2, исключить продавцов с одной датой.
Диалог
Я специально забыл GROUP BY → бот подсказал.
Потом бот спросил, как исключить продавцов с одной датой → добавил COUNT(*) OVER (...) >= 2 Что на самом деле было избыточно, так как rownum покрывал этот юз кейс, на что я указал агенту =)
===
2. Индекс под ORDER BY … LIMIT
Какой индекс стоит использовать
SELECT order_id, total_amount
FROM orders
WHERE customer_id = $1
AND status = 'shipped'
ORDER BY order_date DESC
LIMIT 10;
Варианты индексов
A. (status)
B. (customer_id, status, order_date DESC, order_id)
C. (order_date)
D. (status, customer_id)
Диалог
- Сначала выбрал D.
- Бот уточнил про сортировку и LIMIT и задал наводящий вопрос по high/low cardinality.
- Перешёл на B — бот подтвердил, что это оптимально, и задал вопрос, надо ли что-то изменять если мы хотим поменять сортировку по order_date по нарастающей и ухудшится ли план, если убрать order_id из индекса
===
3. Теория: write-skew
Формулировка
Пояснить, что такое write-skew на уровне REPEATABLE READ и почему SERIALIZABLE это ловит.
Диалог
Я совершенно не помнил про write-skew и описал lost-update проблему, но затем бот зафоллоапил пример, и уточнил про отличие от lost-update
В рамках SERIALIZABLE обсуждение было про predicate locking
===
4. Рекурсивный CTE: зарплата команды
Таблица employees(emp_id, manager_id, salary), у CEO manager_id is null
Для каждого менеджера посчитать кол-во и сумму зарплат всех подчинённых (прямых и косвенных).
Диалог
Всеми любимые задачи на рекурсию =) Причем эта была не классический top down, а down to top, что было более интересное
Я несколько раз косячил в SQL, и бот поправлял и делал follow-up примерно, как бы это было бы на интервью
===
5. Когда нужен PL/pgSQL
Выбрать, где процедурное расширение уместнее чистого SQL.
Варианты
A. Обновить все строки сложной формулой.
B. Пройти курсором, вызвать веб-API для каждой строки, сохранить ответ.
C. Джойнить три большие таблицы, агрегировать и вернуть отчёт.
D. Ночью обновлять материализованное представление.
Диалог
Выбрал B. Бот согласился. Follow up question:
What precaution would you take to avoid bogging down the DB while that PL/pgSQL loop waits on each API call?
===
6. JOIN + агрегаты: завышенная сумма
Формулировка
Дебаг запроса - Problem: Finance says some “total_spent” figures are *too large*.
SELECT
c.customer_id,
c.name,
SUM(o.total_amount) AS total_spent,
SUM(oi.quantity) AS total_items
FROM customers c
LEFT JOIN orders o
ON o.customer_id = c.customer_id
LEFT JOIN order_items oi
ON oi.order_id = o.order_id
WHERE o.status = 'shipped'
GROUP BY c.customer_id, c.name;
Тут бот ожидал 4 изменения и переписанный запрос. Бот указаывал опечатки, проверял наличие alias
===
Итог
- Бот ведёт сценарий, даёт ровно столько подсказок, сколько нужно, иногда ожидает избыточного ответа
- После сессии остаётся готовый «черновик» диалога со всеми вариантами и решениями
- Стоит попробовать помокать с чатгпт, особенно если у вас есть готовый список вопросов и / или тематика, которую вы хотите проработать. Однако я думаю, есть и более подходящие агенты (Если кто-то знает какие-нибудь, посоветуйте в комментариях)