Главное, чтобы работало ...
Или зачем вообще нужен код-стайл в SQL?
Очень часто можно услышать:
Какая разница, как написан SQL код? Главное, чтобы запрос работал.
И формально это правда.
Если запрос возвращает правильные данные - задача вроде бы решена.
Об этом порассуждаем чуть ниже, а пока....
Подписывайся, если интересно как устроен мир аналитика!
В моем канале Аналитика FM выпуски про расчет Retention в разных бизнесах.Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Особенность того, что необходимо "использовать" код-стайл при написании SQL запросов заключается в том, что SQL почти никогда не пишется один раз.
Его:
читают коллеги
правят через полгода
копируют в другие отчёты
используют как основу для новых запросов
И вот в этот момент становится понятно, зачем существует код-стайл.
Код-стайл - это договорённость о том, как писать код, чтобы его было легко читать, понимать и поддерживать.
Это не про красоту ради красоты.
Это про понятность.
В код-стайл обычно входят правила:
форматирования запроса
именования таблиц и алиасов
расположения JOIN
оформления условий
структуры сложных запросов
По сути это язык, на котором разработчики и аналитики читают код друг друга.
Почему "красивый SQL" важен
SQL отличается от многих языков тем, что он декларативный.
Ты описываешь не процесс, а результат.
И если структура запроса хаотичная, читать его становится очень тяжело.
Посмотрите на такой запрос:
SELECT a.id,b.name,sum(o.amount)
FROM users a JOIN orders o ON a.id=o.user_id
JOIN products b ON o.product_id=b.id
WHERE o.status='paid' AND o.created_at>'2025-01-01'
GROUP BY a.id,b.name;
Он работает.
Но мозг тратит энергию просто на то, чтобы разобрать структуру.
Теперь тот же запрос, но оформленный:
SELECT
u.id,
SUM(o.amount) AS revenue
FROM users u
JOIN orders o
ON u.id = o.user_id
JOIN products p
ON o.product_id = p.id
WHERE o.status = 'paid'
AND o.created_at > '2025-01-01'
GROUP BY
u.id,
Логика читается почти как текст.
Что обычно входит в хороший SQL-код-стайл
1️⃣ Ключевые слова - в одном регистре
Чаще всего пишут в верхнем:
SELECT
FROM
WHERE
GROUP BY
Это помогает быстро видеть структуру запроса.
2️⃣ Каждая логическая часть - с новой строки
Структура запроса должна читаться сверху вниз:
SELECT
FROM
JOIN
WHERE
GROUP BY
HAVING
ORDER BY
Это базовая навигация по SQL.
3️⃣ JOIN всегда выносят отдельно
Плохой вариант:
FROM users u, orders o
WHERE u.id = o.user_id
Хороший вариант:
FROM users u
JOIN orders o
ON u.id = o.user_id
Так видно:
какие таблицы участвуют
по каким ключам они связаны
4️⃣ Алиасы должны быть понятными
Плохой стиль:
SELECT a,b,c
FROM table1 t1
JOIN table2 t2
Хороший стиль:
users u
orders o
payments p
Код читается быстрее.
5️⃣ Сложные условия — разбивать
Вместо:
WHERE status='paid' AND created_at>'2025-01-01' AND country='DE'
Лучше:
WHERE status = 'paid'
AND created_at > '2025-01-01'
AND country = 'DE'
Так легче искать ошибки.
6️⃣ Вычисления лучше именовать
Плохой вариант:
SUM(amount)
Лучше:
SUM(amount) AS total_revenue
Через месяц вы не будете вспоминать, что именно считалось.
Есть ещё один важный момент
SQL-код почти всегда живет дольше, чем его автор помнит контекст.
Запрос, написанный сегодня:
могут открыть через год
могут использовать в другой задаче
могут передать другому аналитику
И если код написан хаотично, человек сначала будет разбираться в структуре, а уже потом в логике.
Хороший код-стайл - это уважение
Уважение:
к коллегам
к будущему себе
к системе, в которой работает код
Потому что чаще всего через несколько месяцев вы открываете свой старый SQL…
и думаете:
Кто это вообще написал?
И очень приятно, когда ответ:
Я. И я понимаю, что здесь происходит.
В моем канале Аналитика FM все про мышление аналитика, про инструменты аналитика.
Мы рассматриваем SQL и Python в применении к данным.Этот канал я веду с нуля подписчиков. Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!
