VelStyling

Если ты когда-нибудь писал длинный SQL-запрос и в какой-то момент ловил себя на мысли:
"Я уже сам не понимаю, что здесь происходит" - поздравляю, ты подошёл к моменту, где появляются временные таблицы.

В канале Аналитика FM я часто разбираю такие ситуации - когда задача вроде решаема, но без нормальной структуры превращается в кашу.

Что такое временная таблица

Это обычная таблица…
только с одним отличием:

👉 она живёт временно и потом исчезает

Ты создаёшь её:

• чтобы сохранить промежуточный результат

• поработать с ним

• и не засорять основную базу

Тебе нужно:

• взять заказы

• отфильтровать только оплаченные

• посчитать выручку

• добавить сегментацию пользователей

• ещё пару условий сверху

Можно написать один огромный запрос.

А можно сделать по-другому:

1. Сначала собрать "чистые заказы"

2. Потом на их основе считать метрики

3. Потом добавлять бизнес-логику

И вот тут временные таблицы начинают играть.

Как это выглядит

CREATE TEMP TABLE temp_orders AS
SELECT *
FROM orders
WHERE status = 'paid';

Создаем промежуточный слой данных.

А потом работаем уже с ним.

SELECT user_id, SUM(amount)
FROM temp_orders
GROUP BY user_id;

Зачем это нужно

1️⃣ Разделить сложную логику

Вместо одного "монстра":

• ты разбиваешь задачу на шаги

• каждый шаг понятен

• легче дебажить

2️⃣ Переиспользовать результат

Если один и тот же кусок данных нужен несколько раз:

• не нужно каждый раз пересчитывать

• можно сохранить и использовать

3️⃣ Ускорить запросы

Иногда:

• тяжёлый JOIN

• сложная фильтрация

👉 выгодно посчитать один раз и сохранить результат

4️⃣ Не засорять базу

Если ты создашь обычную таблицу:

• она останется

• её надо потом удалять

• она может мешать другим

Временная таблица:

• живёт в рамках сессии

• автоматически исчезает

Когда это особенно полезно

• сложные аналитические расчёты

• многоступенчатые преобразования данных

• работа с "грязными" данными

• отладка логики

Важный нюанс

Временные таблицы - это не единственный инструмент.

Есть ещё:

• CTE (WITH)

• подзапросы

Но:

👉 CTE - это "логика в одном запросе"
👉 временные таблицы - это "разбивка на реальные шаги"

Иногда CTE читается тяжело.
А временные таблицы дают ощущение "пайплайна".

Где часто ошибаются

• создают временные таблицы без необходимости

• забывают, что они завязаны на сессию

• используют их там, где проще CTE

То есть это инструмент - не серебряная пуля.

Самая простая мысль

Временная таблица - это способ остановиться посередине запроса и зафиксировать результат

И иногда именно это спасает:

• читаемость

• производительность

• и твои нервы

В канале Аналитика FM (клик :-) )я рассказываю про продуктовые метрики в разных бизнесах. В чем особенности и нюансы. Серия постов про средний чек уже готова.

Подписывайся, если интересно интересно разбираться в особенностях работы аналитика.

Или превращение длинной таблицы в широкую

В канале Аналитика FM я часто про это пишу - потому что аналитика заканчивается не на запросе, а на том, как ты показал результат.

Подписывайся!

Представь, у тебя есть данные:

| user_id | metric | value |
| ----------- | ------------- | -------- |
| 1 | revenue | 100 |
| 1 | orders | 2 |

Это длинная таблица.

Она удобна для хранения:

• гибкая

• легко добавлять новые метрики

• хорошо ложится в модели данных

Но попробуй быстро понять:

• кто сколько потратил

• у кого сколько заказов

• и сравнить это между собой

Неудобно.

А теперь та же информация:

| user_id | revenue | orders |
| ------------ | ------------- | ---------- |
| 1 | 100 | 2 |

Это широкая таблица.

И вот тут уже:

• метрики рядом

• сравнение - в одну секунду

• можно считать новые показатели

Что значит "превратить длинную таблицу в широкую"

Это значит:

взять значения из строк и разложить их по колонкам

То есть:

• metric → становится названиями колонок

• value → становится значениями в этих колонках

Ты буквально "разворачиваешь" данные.

Причём здесь pivot table

На самом деле, это и есть pivot.

Слово pivot - это "поворот".
Ты поворачиваешь таблицу так, чтобы:

• строки стали колонками

• данные стали наглядными

Если ты работал в Excel - ты это уже делал:
сводная таблица = pivot table.

В SQL это можно реализовать так:

SELECT
user_id,
SUM(CASE WHEN metric = 'revenue' THEN value END) AS revenue,
SUM(CASE WHEN metric = 'orders' THEN value END) AS orders
FROM table
GROUP BY user_id;

Зачем это вообще нужно

Потому что аналитика - это не про "достать данные".
Это про сделать их понятными.

Широкая таблица нужна, когда ты:

• строишь отчёт

• показываешь результат бизнесу

• считаешь метрики между собой

Длинная таблица - когда:

• хранишь данные

• работаешь с событиями

• строишь модели

Где чаще всего ошибаются

Самая частая ошибка - пытаться всё делать в широком формате.

Это ломает гибкость:

• добавилась новая метрика → переписывай запрос

• данные перестают масштабироваться

Правильный подход:

• храним - в длинном виде

• показываем - в широком

Длинная таблица - это про хранение
Широкая таблица - это про понимание

И pivot - это просто инструмент, который помогает перейти от одного к другому.

И если ты хочешь не просто писать SQL, а реально чувствовать данные и понимать, как их правильно показывать,
в Аналитика FM я как раз разбираю такие вещи - простым языком, но с реальным смыслом.

Если ты только начинаешь разбираться в данных, то очень быстро сталкиваешься с кучей аббревиатур.
DDL, DML, ещё что-то… И кажется, что это какие-то сложные термины из учебника.

Но на самом деле всё гораздо проще.

И в канале Аналитика FM я как раз стараюсь разбирать такие вещи без заумных формулировок - через логику и реальные сценарии.

Представь, что база данных - это квартира

• есть стены

• есть комнаты

• есть мебель

И есть вещи, которые ты туда кладёшь.

Так вот:

👉 DDL - это про квартиру
👉 DML - это про вещи внутри неё

DDL (Data Definition Language) - это команды, которые создают и изменяют структуру базы.

То есть всё, что связано с "построить" или "переделать".

CREATE TABLE users (...);
ALTER TABLE users ADD COLUMN age INT;
DROP TABLE users;

• CREATE - ты создал новую "комнату"

• ALTER - передвинул стену или добавил полку

• DROP - снёс всё к чертям

📌 Важно:
DDL не трогает сами данные.
Он создаёт условия, где эти данные будут жить.

DML (Data Manipulation Language) - это уже про работу с данными.

SELECT * FROM users;
INSERT INTO users VALUES (...);
UPDATE users SET age = 30;
DELETE FROM users WHERE id = 1;

Это то, что делает аналитик каждый день:

• посмотрел данные (SELECT)

• добавил (INSERT)

• изменил (UPDATE)

• удалил (DELETE)

📌 Здесь ты уже работаешь не с "комнатой", а с тем, что внутри неё.

В чём реальное отличие

Не в терминах, а в сути:

• DDL отвечает на вопрос: Как устроены данные?

• DML отвечает на вопрос: Что происходит с данными?

Как это используется на практике

Тебе нужно посчитать метрику.

Но:

• нет нужной таблицы

• не хватает колонок

• данные лежат неудобно

👉 Тогда сначала приходит DDL:
создают таблицу, добавляют поля, настраивают структуру.

И только потом приходит DML:
ты пишешь SELECT, считаешь, анализируешь.

DDL и DML - это не просто разные команды.
Это разные уровни ответственности.

• DDL чаще делают разработчики, инженеры, архитекторы

• DML - это зона аналитиков

Но хороший аналитик всё равно должен понимать DDL.
Иначе он не понимает, почему данные лежат именно так.

DDL обычно:

• применяется сразу

• сложнее откатывается

DML:

• можно обернуть в транзакцию

• можно отменить

Это важно, когда ты начинаешь работать не только с SELECT, но и с изменением данных.

DDL - это "построить систему"
DML - это "жить внутри неё и работать с данными"

Если ты хочешь начать действительно понимать данные, а не просто писать запросы -
такие базовые вещи дают фундамент.

В канале Аналитика FM я как раз разбираю такие темы:
без усложнений, но с пониманием того, как это работает в реальной работе аналитика.

Разбор метрик Retention и Revenue в разных сферах бизнеса уже в канале.

Подписывайся!

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

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