Проверяя работы студентов на нашем курсе «Аналитик данных», мы часто встречаемся с ошибкой избыточных подзапросов. То, что можно было решить в один запрос, студенты решают за 3.
✅ Почему так происходит?
Из-за того, что многие пишут SQL-запросы так же, как это «звучит» в их голове. А SQL работает немного иначе — на нём нужно буквально «мыслить». Но это приходит с опытом, за счёт большого количества практики (как правило, к концу модуля по SQL такие ошибки уже никто не делает).
✅ Пример
Он будет довольно простым — наверняка вы бы написали здесь сразу один запрос. Однако эта ошибка проявляется даже в таких случаях, чего уж говорить про более сложные.
Итак, задача: вывести id транзакции и предыдущую сумму транзакции со знаком минус. Вот решение студента:
SELECT id,
LAG(neg) OVER(ORDER BY id)
AS lg
FROM (
SELECT id, sm, -sm AS neg
FROM (
SELECT id, sum AS sm
FROM transactions t
) t
) t1
И это ещё не всё, можно и побольше накрутить. Но зачем так, если можно так:
SELECT id, LAG(-sum) OVER(ORDER BY id)
FROM transactions t
✅ А как писать такие запросы?
Отсекайте лишнее. Напишите запрос так, как получилось. Затем попробуйте упростить. Затем ещё. И так до тех пор, пока не получите минимально возможный запрос.
✅ Совет
Не старайтесь сразу писать сложные и оптимизированные конструкции. Напишите сначала, как сможете, а затем пытайтесь упростить запрос. Как говорил знаменитый дядюшка Кнут: «Преждевременная оптимизация — корень всех зол».
Ставьте 🔥, если полезно, и сохраняйте, чтобы не потерять!
📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS