Главное, чтобы работало ...⁠⁠

Или зачем вообще нужен код-стайл в 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,

p.name,

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,

p.name;

Логика читается почти как текст.

Что обычно входит в хороший 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 в применении к данным.

Этот канал я веду с нуля подписчиков. Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!