🔍 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🟰 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤
Системный аналитик без SQL — как архитектор без чертежей. Это не просто «инструмент», а способ мышления.
📊 ЗАЧЕМ SQL АНАЛИТИКУ?
1️⃣ ПОНИМАНИЕ ДАННЫХ ИЗНУТРИ
ER-диаграмма показывает связи, SQL показывает реальные отношения:
2️⃣ ВЕРИФИКАЦИЯ ТРЕБОВАНИЙ
«Клиенты делают ≤5 заказов в месяц» — правда?
3️⃣ ПРОЕКТИРОВАНИЕ ОТЧЕТНОСТИ
Аналитик проектирует как бизнес увидит данные:
🛠 ПРАКТИЧЕСКИЙ КЕЙС: РЕКОМЕНДАЦИИ ТОВАРОВ
Перед разработкой проверяем данные:
Вывод аналитика:
Если avg_orders < 2 → рекомендации неэффективны → меняем требования!
📈 3 УРОВНЯ SQL-НАВЫКОВ:
👉 JUNIOR: Базовые SELECT + WHERE
👉 MIDDLE: JOIN + GROUP BY + подзапросы
👉 SENIOR: Оконные функции + сложная аналитика
🎯 КОГДА ИСПОЛЬЗОВАТЬ SQL В РАБОТЕ:
✅ ДО проектирования → Анализ текущих данных
✅ ВО ВРЕМЯ сбора требований → Проверка реализуемости
✅ ПРИ тестировании → Верификация корректности
✅ ПОСЛЕ внедрения → Анализ impact на метрики
💡🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 превращает бизнес-вопросы в данные, а данные — в решения.
Вопрос бизнеса: «Почему падают продажи?»
Ответ через SQL:
sql
-- Сравнение с прошлым годом + анализ по категориям
-- + конверсия по этапам + динамика среднего чека
→ Конкретные цифры, а не догадки!
🚀🔤 🔤 🔤 🔤 🔤 🔤 ➖ 🔤 🔤 🔤 🔤 🔤
Знаю структуру БД проекта
Умею проверять гипотезы запросами
Проектирую отчеты через SQL
Оптимизирую сложные запросы
Говорю с разработчиками на одном языке
SQL — это не про синтаксис. Это про понимание того, как данные превращаются в бизнес-ценность. 💎
#SQL
Системный аналитик без SQL — как архитектор без чертежей. Это не просто «инструмент», а способ мышления.
📊 ЗАЧЕМ SQL АНАЛИТИКУ?
1️⃣ ПОНИМАНИЕ ДАННЫХ ИЗНУТРИ
ER-диаграмма показывает связи, SQL показывает реальные отношения:
-- Сколько заказов в среднем у клиента?
SELECT ROUND(AVG(order_count), 1)
FROM (SELECT customer_id, COUNT(*) as order_count
FROM orders GROUP BY customer_id) stats;
→ Результат: не «один ко многим», а «в среднем 3.2 заказа»
2️⃣ ВЕРИФИКАЦИЯ ТРЕБОВАНИЙ
«Клиенты делают ≤5 заказов в месяц» — правда?
SELECT orders_per_month, COUNT(DISTINCT customer_id)
FROM monthly_orders
GROUP BY orders_per_month
HAVING orders_per_month > 5;
→ Оказывается, 5% клиентов делают 10+ заказов!
3️⃣ ПРОЕКТИРОВАНИЕ ОТЧЕТНОСТИ
Аналитик проектирует как бизнес увидит данные:
-- Воронка продаж за неделю
SELECT
stage,
users,
ROUND(users * 100.0 / LAG(users) OVER(ORDER BY step), 1) || '%' as conversion
FROM funnel_stages;
🛠 ПРАКТИЧЕСКИЙ КЕЙС: РЕКОМЕНДАЦИИ ТОВАРОВ
Перед разработкой проверяем данные:
-- Достаточно ли истории покупок?
SELECT COUNT(DISTINCT customer_id) as active_clients,
AVG(orders_per_client) as avg_orders
FROM (SELECT customer_id, COUNT(*) as orders_per_client
FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2) data;
Вывод аналитика:
Если avg_orders < 2 → рекомендации неэффективны → меняем требования!
📈 3 УРОВНЯ SQL-НАВЫКОВ:
👉 JUNIOR: Базовые SELECT + WHERE
SELECT * FROM users WHERE reg_date > '2024-01-01';
👉 MIDDLE: JOIN + GROUP BY + подзапросы
SELECT department, COUNT(orders), SUM(revenue)
FROM users JOIN orders ON users.id = orders.user_id
GROUP BY department HAVING COUNT(orders) > 10;
👉 SENIOR: Оконные функции + сложная аналитика
WITH trends AS (
SELECT user_id, week,
LAG(events) OVER(PARTITION BY user_id ORDER BY week) as prev
FROM weekly_activity
)
SELECT week, SUM(CASE WHEN events > prev THEN 1 ELSE 0 END) as growing_users
FROM trends GROUP BY week;
🎯 КОГДА ИСПОЛЬЗОВАТЬ SQL В РАБОТЕ:
✅ ДО проектирования → Анализ текущих данных
✅ ВО ВРЕМЯ сбора требований → Проверка реализуемости
✅ ПРИ тестировании → Верификация корректности
✅ ПОСЛЕ внедрения → Анализ impact на метрики
💡
Вопрос бизнеса: «Почему падают продажи?»
Ответ через SQL:
sql
-- Сравнение с прошлым годом + анализ по категориям
-- + конверсия по этапам + динамика среднего чека
→ Конкретные цифры, а не догадки!
🚀
Знаю структуру БД проекта
Умею проверять гипотезы запросами
Проектирую отчеты через SQL
Оптимизирую сложные запросы
Говорю с разработчиками на одном языке
SQL — это не про синтаксис. Это про понимание того, как данные превращаются в бизнес-ценность. 💎
#SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Приветствую, коллеги! Сегодня разберем, почему SQL — это не удел разработчиков, а ключевой навык для системного аналитика, который напрямую влияет на качество вашей работы. Даже если вы не пишете запросы каждый день, понимание SQL открывает новые горизонты. Поехали! 🚀
🤔 Зачем аналитику SQL?
Самостоятельность в работе с данными
Вместо того чтобы просить разработчика «выгрузите мне заказы за прошлый месяц», вы можете сделать это сами. Это экономит время и снижает нагрузку на команду.
Глубокое понимание структуры данных
Через SQL вы видите, как реально связаны таблицы, где хранятся ключевые атрибуты, как организована бизнес-логика. Это помогает находить корень проблем в требованиях.
Верификация данных и тестирование
После реализации функции вы можете проверить, корректно ли записались данные, без ожидания готового отчета. Это качественно повышает вашу экспертизу.
Диалог на одном языке с командой
Обсуждая с разработчиками сложные выборки или ограничения целостности, вы говорите на понятном им языке, что ускоряет коммуникацию и повышает доверие.
📚 Что именно нужно знать?
Вам не нужно быть гуру оптимизации, но обязательно освоить:
✅ Базовые операции
SELECT, WHERE, ORDER BY, GROUP BY, агрегатные функции (COUNT, SUM, AVG). Без этого никуда!
✅ Соединения таблиц (JOIN)
Понимать разницу между INNER, LEFT, RIGHT JOIN. Это основа для работы с нормализованными данными.
✅ Фильтрация и сортировка
Работа с NULL, операторы LIKE, IN, BETWEEN. Умение правильно фильтровать — залог точных данных.
✅ Аналитические запросы
Использование DISTINCT, HAVING, простые подзапросы (EXISTS, IN). Это поможет в анализе бизнес-процессов.
✅ Структура БД (DDL)
Понимать, что такое таблицы, индексы, первичные и внешние ключи, ограничения (NOT NULL, UNIQUE). Это критически важно для проектирования.
💼 Практические кейсы из жизни аналитика
🎯 Кейс 1: Уточнение требования к отчету
Задача: Бизнес просит отчет «по заказам в статусе «Выполнен» за последний квартал».
Без SQL: Вы передаете формулировку разработчику и ждете.
С SQL: Вы сами смотрите в таблицу Orders, находите поле status_id, проверяете справочник статусов, убеждаетесь, что статус «Выполнен» имеет id=5. Затем пишете запрос с фильтром WHERE status_id = 5 AND order_date >= '2024-01-01'. И сразу видите, что в данных есть нюанс — часть заказов имеет подстатус «Доставка», который тоже считается выполнением. Вы уточняете требование до того, как оно уйдет в разработку!
🎯 Кейс 2: Поиск причины бага
Ситуация: Пользователи жалуются, что в новом личном кабинете не отображаются старые заказы.
Без SQL: Вы создаете задачу разработчику: «Разберитесь».
С SQL: Вы делаете запрос к таблице заказов, присоединяя таблицу пользователей. Обнаруживаете, что заказы старше 2023 года не имеют связи с актуальными пользователями из-за миграции данных. Формируете конкретный баг-репорт с примерами order_id и предлагаете вариант исправления. Решение ускоряется в 3 раза!
🎯 Кейс 3: Проектирование интеграции
Задача: Нужно передавать данные о новых пользователях во внешнюю CRM-систему.
Без SQL: Вы описываете: «Передавать ФИО, email и дату регистрации».
С SQL: Вы изучаете таблицу Users, видите, что ФИО разбито на 3 поля, email проверен уникальным индексом, а дата регистрации хранится в формате UTC. В требованиях вы явно указываете источники данных: SELECT first_name, last_name, middle_name, email, created_at FROM Users WHERE id = :newUserId. Техническая команда благодарит за детализацию!
🚀 Как эффективно учить и применять SQL?
Начните с интерактивных тренажеров
SQL-ex, Stepik, Codecademy — отличные площадки для первых шагов без установки СУБД.
Работайте с реальной базой
Попросите у разработчиков дамп тестовой БД вашего проекта. Изучайте связи, пишите запросы к знакомым данным.
Автоматизируйте рутину
#SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
🧩 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 — это ваш навигатор в проекте
Умение писать и читать SQL-запросы даёт вам, как аналитику, три ключевых преимущества:
Глубокое понимание «анатомии» системы. Вы видите, как данные связаны между собой, и можете предсказать, где возникнут проблемы при масштабировании.
Проверка требований на реализуемость. Можно сразу набросать структуру будущих таблиц и выявить противоречия в требованиях до этапа разработки.
Предотвращение архитектурных ошибок. Помогает оценить, как сегодняшнее решение повлияет на завтрашние возможности системы. Часто проще потратить день на проектирование, чем месяцы на исправление «костылей».
💥 Боль из реальных проектов: когда незнание SQL било по срокам
Давайте на примерах. Думаете, я преувеличиваю?
Кейс 1: ФИО одной строкой. В проекте было решено хранить ФИО пользователя в одном поле full_name. Казалось бы, мелочь. Но когда потребовалась интеграция с госсистемой, где ФИО передаются тремя раздельными полями, пришлось:
Писать хрупкий алгоритм разбивки строки (а как быть с двойными фамилиями или отчествами вроде «оглы»?).
Менять API, интерфейсы и все интеграции.
Результат: три месяца незапланированной работы вместо одной маленькой фичи.
Кейс 2: Один владелец на машину. В системе для автосервиса изначально заложили, что у машины один владелец. В жизни же часто бывает два-три совладельца. Пришлось экстренно менять связь в БД с «один-ко-многим» на «многие-ко-многим», что потянуло за собой лавину изменений.
Этих проблем можно было бы избежать, если бы на этапе анализа и проектирования кто-то спросил: «А как эти данные лежат в базе?» и смог проверить это сам.
🛠 Ваш базовый арсенал: SQL-запросы, которые стоит освоить в первую очередь
Теория — это хорошо, но давайте к практике. Вот 5 типов запросов, которые стоит отточить. Для примеров возьмем упрощенную модель интернет-магазина.
🚀🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤 ❓
1. SELECT и WHERE: Видеть и фильтровать
Базовый запрос — ваш главный инструмент изучения данных.
sql
-- Выбрать всех активных пользователей из Москвы, зарегистрированных после 2023 года
SELECT first_name, last_name, email
FROM customers
WHERE city = 'Москва'
AND registration_date >= '2023-01-01'
AND status = 'active';
2. JOIN: Связывать сущности
Суть реляционных баз — в связях. JOIN помогает их восстановить.
sql
-- Узнать, какие товары и в каком количестве заказал каждый клиент
SELECT c.first_name, c.last_name, p.product_name, oi.quantity
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id;
3. GROUP BY и агрегатные функции: Считать и обобщать
Для анализа и отчетов без этого никуда.
4. Подзапросы и CTE (WITH): Декомпозировать сложные вопросы
Когда запрос становится слишком сложным, его нужно разбить на части.
5. Оконные функции (OVER): Анализировать в контексте
Мощный инструмент для скользящих сумм, ранжирования и сравнений без потери детализации.
#SQL
Умение писать и читать SQL-запросы даёт вам, как аналитику, три ключевых преимущества:
Глубокое понимание «анатомии» системы. Вы видите, как данные связаны между собой, и можете предсказать, где возникнут проблемы при масштабировании.
Проверка требований на реализуемость. Можно сразу набросать структуру будущих таблиц и выявить противоречия в требованиях до этапа разработки.
Предотвращение архитектурных ошибок. Помогает оценить, как сегодняшнее решение повлияет на завтрашние возможности системы. Часто проще потратить день на проектирование, чем месяцы на исправление «костылей».
💥 Боль из реальных проектов: когда незнание SQL било по срокам
Давайте на примерах. Думаете, я преувеличиваю?
Кейс 1: ФИО одной строкой. В проекте было решено хранить ФИО пользователя в одном поле full_name. Казалось бы, мелочь. Но когда потребовалась интеграция с госсистемой, где ФИО передаются тремя раздельными полями, пришлось:
Писать хрупкий алгоритм разбивки строки (а как быть с двойными фамилиями или отчествами вроде «оглы»?).
Менять API, интерфейсы и все интеграции.
Результат: три месяца незапланированной работы вместо одной маленькой фичи.
Кейс 2: Один владелец на машину. В системе для автосервиса изначально заложили, что у машины один владелец. В жизни же часто бывает два-три совладельца. Пришлось экстренно менять связь в БД с «один-ко-многим» на «многие-ко-многим», что потянуло за собой лавину изменений.
Этих проблем можно было бы избежать, если бы на этапе анализа и проектирования кто-то спросил: «А как эти данные лежат в базе?» и смог проверить это сам.
🛠 Ваш базовый арсенал: SQL-запросы, которые стоит освоить в первую очередь
Теория — это хорошо, но давайте к практике. Вот 5 типов запросов, которые стоит отточить. Для примеров возьмем упрощенную модель интернет-магазина.
🚀
1. SELECT и WHERE: Видеть и фильтровать
Базовый запрос — ваш главный инструмент изучения данных.
sql
-- Выбрать всех активных пользователей из Москвы, зарегистрированных после 2023 года
SELECT first_name, last_name, email
FROM customers
WHERE city = 'Москва'
AND registration_date >= '2023-01-01'
AND status = 'active';
2. JOIN: Связывать сущности
Суть реляционных баз — в связях. JOIN помогает их восстановить.
sql
-- Узнать, какие товары и в каком количестве заказал каждый клиент
SELECT c.first_name, c.last_name, p.product_name, oi.quantity
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id;
3. GROUP BY и агрегатные функции: Считать и обобщать
Для анализа и отчетов без этого никуда.
-- Посчитать выручку и средний чек по каждому городу
SELECT
c.city,
COUNT(o.order_id) as total_orders, -- количество заказов
SUM(o.total_amount) as total_revenue, -- общая выручка
AVG(o.total_amount) as avg_order_value -- средний чек
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.city;
4. Подзапросы и CTE (WITH): Декомпозировать сложные вопросы
Когда запрос становится слишком сложным, его нужно разбить на части.
-- Найти клиентов, которые делали заказы на сумму больше средней
WITH avg_order_value AS ( -- CTE: вычисляем средний чек один раз
SELECT AVG(total_amount) as avg_amount FROM orders
)
SELECT c.first_name, c.last_name, o.total_amount
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.total_amount > (SELECT avg_amount FROM avg_order_value);
5. Оконные функции (OVER): Анализировать в контексте
Мощный инструмент для скользящих сумм, ранжирования и сравнений без потери детализации.
-- Для каждого заказа показать сумму заказа и общую сумму всех заказов его клиента
SELECT
o.order_id,
o.customer_id,
o.total_amount,
SUM(o.total_amount) OVER (PARTITION BY o.customer_id) as customer_lifetime_value
FROM orders o;
#SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
📊 От SQL к диаграммам: Как превратить сырые данные в наглядные процессы
Привет снова! 👋 В прошлом посте мы с вами научились «вытаскивать» критически важные инсайты из базы данных с помощью SQL. 🎣 Мы обнаружили, что пользователи массово «отваливаются» на переходе с главного экрана к созданию проекта. 📉
Но что делать дальше? 🤔 Как перейти от цифр и таблиц к понятным артефактам, которые «заговорят» с разработчиками, дизайнерами и продуктологами? 💬
Ответ: визуализируйте! 🎨 Следующий ключевой навык сисаналитика — превращать данные в наглядные модели. Сегодня покажу, как на основе SQL-анализа быстро построить Sequence Diagram (Диаграмму последовательности), которая сразу покажет проблемное место в процессе. 📈
🧩 Шаг 4: Из данных — в диаграмму (на примере Mermaid.js)
Допустим, наш SQL-анализ воронки дал четкую последовательность событий и точку сбоя. 🎯 Теперь нам нужно смоделировать идеальный и фактический сценарий, чтобы все заинтересованные стороны увидели проблему буквально за 10 секунд. ⏱️
Воспользуемся текстовым языком Mermaid — его можно использовать в Confluence, GitLab/GitHub, Notion и даже в Telegram (через ботов). 🤖 Это гениально для сисаналитика: диаграмма хранится как код, ее легко править и версионировать. 🔄
Код 1: Идеальный сценарий (как мы задумывали) 🌟
Что видно? Четкий, линейный, успешный поток. Именно так мы представляли себе процесс. 💭
Код 2: Фактический сценарий (как показали данные) 📊
А теперь встроим в диаграмму наш ключевой инсайт из прошлого поста — 80% пользователей не совершают целевое действие после главного экрана. 😱
Вот он — момент истины! 🎯 Диаграмма, основанная на реальных данных, кристально ясно показывает:
Где происходит сбой (после Главного экрана). 📍
Масштаб проблемы (соотношение 20/80). ⚖️
Альтернативное поведение пользователей (блуждание). 🌀
🤔 Как это использовать в работе системного аналитика? 🛠
В презентации для стейкхолдеров: 🎤 Одна такая диаграмма заменит 10 слайдов с таблицами. Она фокусирует обсуждение на конкретной проблеме, а не на догадках. 🎯
В техническом задании / user story: 📝 Диаграмма становится наглядным контекстом для требования: «Как видно из модели поведения, 80% пользователей не находят кнопку "Создать проект" на главном экране. Необходимо повысить ее конверсию до 50%...». 📊
Для мозгового штурма с дизайнерами: 🧠 Показываем не «сделайте кнопку красивее», а «здесь у нас разрыв в процессе, давайте предложим решения, которые вернут пользователя в целевой поток». 💡
Для постановки задачи разработчикам на логгинг: ⚙️ Диаграмма помогает понять, какие новые события нужно начать логировать (например, help_section_viewed или time_spent_on_main_screen), чтобы в следующий раз анализ был еще точнее. 🔍
#SQL
Привет снова! 👋 В прошлом посте мы с вами научились «вытаскивать» критически важные инсайты из базы данных с помощью SQL. 🎣 Мы обнаружили, что пользователи массово «отваливаются» на переходе с главного экрана к созданию проекта. 📉
Но что делать дальше? 🤔 Как перейти от цифр и таблиц к понятным артефактам, которые «заговорят» с разработчиками, дизайнерами и продуктологами? 💬
Ответ: визуализируйте! 🎨 Следующий ключевой навык сисаналитика — превращать данные в наглядные модели. Сегодня покажу, как на основе SQL-анализа быстро построить Sequence Diagram (Диаграмму последовательности), которая сразу покажет проблемное место в процессе. 📈
🧩 Шаг 4: Из данных — в диаграмму (на примере Mermaid.js)
Допустим, наш SQL-анализ воронки дал четкую последовательность событий и точку сбоя. 🎯 Теперь нам нужно смоделировать идеальный и фактический сценарий, чтобы все заинтересованные стороны увидели проблему буквально за 10 секунд. ⏱️
Воспользуемся текстовым языком Mermaid — его можно использовать в Confluence, GitLab/GitHub, Notion и даже в Telegram (через ботов). 🤖 Это гениально для сисаналитика: диаграмма хранится как код, ее легко править и версионировать. 🔄
Код 1: Идеальный сценарий (как мы задумывали) 🌟
sequenceDiagram
actor User
participant App
participant Backend
User->>App: Регистрация
App->>Backend: Отправка данных
Backend-->>App: Подтверждение ✅
App->>User: Показ онбординга
User->>App: Клик "Далее"
App->>User: Открытие главного экрана
Note over User,App: Ключевое действие! 🎯
User->>App: Клик "Создать проект"
App->>Backend: Запрос на создание
Backend-->>App: Успех 🎉
App->>User: Проект создан 🏆
Что видно? Четкий, линейный, успешный поток. Именно так мы представляли себе процесс. 💭
Код 2: Фактический сценарий (как показали данные) 📊
А теперь встроим в диаграмму наш ключевой инсайт из прошлого поста — 80% пользователей не совершают целевое действие после главного экрана. 😱
sequenceDiagram
actor User
participant App
participant Backend
User->>App: Регистрация
App->>Backend: Отправка данных
Backend-->>App: Подтверждение ✅
App->>User: Показ онбординга
User->>App: Клик "Далее"
App->>User: Открытие главного экрана
Note right of User: 📈 ПО ПОВЕДЕНЧЕСКИМ ДАННЫМ:<br/>🔥 80% пользователей здесь<br/>🌀 уходят в "блуждание"<br/>🚪 или покидают приложение.
alt Успешный путь (20%) 🎯
User->>App: Клик "Создать проект"
App->>Backend: Запрос на создание
Backend-->>App: Успех ✅
App->>User: Проект создан 🏆
else Проблемный путь (80%) 🚨
User->>App: Блуждание по другим разделам 🗺
App->>User: Показ нерелевантного контента 📺
User->>App: Закрытие приложения / бездействие ❌
end
Вот он — момент истины! 🎯 Диаграмма, основанная на реальных данных, кристально ясно показывает:
Где происходит сбой (после Главного экрана). 📍
Масштаб проблемы (соотношение 20/80). ⚖️
Альтернативное поведение пользователей (блуждание). 🌀
🤔 Как это использовать в работе системного аналитика? 🛠
В презентации для стейкхолдеров: 🎤 Одна такая диаграмма заменит 10 слайдов с таблицами. Она фокусирует обсуждение на конкретной проблеме, а не на догадках. 🎯
В техническом задании / user story: 📝 Диаграмма становится наглядным контекстом для требования: «Как видно из модели поведения, 80% пользователей не находят кнопку "Создать проект" на главном экране. Необходимо повысить ее конверсию до 50%...». 📊
Для мозгового штурма с дизайнерами: 🧠 Показываем не «сделайте кнопку красивее», а «здесь у нас разрыв в процессе, давайте предложим решения, которые вернут пользователя в целевой поток». 💡
Для постановки задачи разработчикам на логгинг: ⚙️ Диаграмма помогает понять, какие новые события нужно начать логировать (например, help_section_viewed или time_spent_on_main_screen), чтобы в следующий раз анализ был еще точнее. 🔍
#SQL
👍2
📊 SQL ДЛЯ СИСТЕМНОГО АНАЛИТИКА: НЕ ПРОСТО ЗАПРОСЫ, А ИНСТРУМЕНТ ПРИНЯТИЯ РЕШЕНИЙ
Привет, коллеги! 👋 Давайте начистоту: многие думают, что SQL для аналитика — это просто проверить данные. На самом деле, это ваш супер-инструмент для выявления проблем, валидации гипотез и даже сбора требований. Сегодня покажу на реальных кейсах, как SQL спасал проекты. 🦸♂️
🔍 Кейс 1: «Пропавшие транзакции» — как SQL помог обнаружить баг в ТЗ
Ситуация: В платёжной системе после релиза новой фичи часть транзакций «терялась». Разработчики клялись, что всё работает. Поддержка завалена жалобами.
Что сделал аналитик? Вместо долгих совещаний, написал исследовательский запрос:
Что обнаружилось: У 15% пользователей были транзакции со статусом NULL, которые не отображались в интерфейсе.
Причина: В техническом задании не учли сценарий таймаута соединения с банком. Система не знала, как обработать этот случай, и оставляла статус пустым.
Итог: За 20 минут SQL-запроса:
✅ Выявлен конкретный баг
✅ Спасена репутация продукта
✅ Дополнено ТЗ обработкой таймаутов
📈 Кейс 2: «Странные бонусы» — валидация бизнес-логики
Задача: После запуска программы лояльности маркетологи заметили, что бонусов начисляется больше, чем ожидалось.
Вместо того чтобы спрашивать «почему?», аналитик провёл анализ данных:
Открытие: 70% всех бонусов получали пользователи с одним заказом, хотя по логике система должна была начислять больше постоянным клиентам.
Проблема: Ошибка в формуле расчёта — бонусы умножались на коэффициент новизны пользователя, а не на коэффициент лояльности.
Результат: SQL помог не просто найти ошибку, а количественно оценить её влияние на бизнес. 💰
🛠 Кейс 3: «Метрики для руководителя» — когда нужно быстро, но содержательно
Срочный запрос от CEO: «Как идут продажи в новом регионе?»
Вместо дня подготовки отчёта, аналитик за 30 минут сделал:
Почему это эффективно?
Готовый анализ трендов по неделям
Ключевые метрики в одном месте
Инсайты для маркетинга — средний чек на клиента
Основа для принятия решений — стоит ли увеличивать инвестиции в регион
🎯 ВАШИ ДЕЙСТВИЯ НА ЗАВТРА:
Начните с малого: Освойте WHERE, GROUP BY, JOIN — этого хватит для 80% задач
Спрашивайте доступ к БД на проекте (только для чтения!)
Автоматизируйте рутину: Сохраняйте полезные запросы в saved queries
Изучайте оконные функции (OVER, PARTITION BY) — это следующий уровень
Запомните: SQL для аналитика — это не про «базы данных», это про понимание данных. Каждый запрос — это вопрос к системе, и правильный вопрос даёт правильный ответ. 🧠
#SQL
Привет, коллеги! 👋 Давайте начистоту: многие думают, что SQL для аналитика — это просто проверить данные. На самом деле, это ваш супер-инструмент для выявления проблем, валидации гипотез и даже сбора требований. Сегодня покажу на реальных кейсах, как SQL спасал проекты. 🦸♂️
🔍 Кейс 1: «Пропавшие транзакции» — как SQL помог обнаружить баг в ТЗ
Ситуация: В платёжной системе после релиза новой фичи часть транзакций «терялась». Разработчики клялись, что всё работает. Поддержка завалена жалобами.
Что сделал аналитик? Вместо долгих совещаний, написал исследовательский запрос:
SELECT
user_id,
COUNT(CASE WHEN status = 'SUCCESS' THEN 1 END) as success_count,
COUNT(CASE WHEN status = 'FAILED' THEN 1 END) as failed_count,
COUNT(CASE WHEN status IS NULL THEN 1 END) as null_count -- Вот это ключ!
FROM transactions
WHERE created_at >= '2024-10-01'
GROUP BY user_id
HAVING null_count > 0;
Что обнаружилось: У 15% пользователей были транзакции со статусом NULL, которые не отображались в интерфейсе.
Причина: В техническом задании не учли сценарий таймаута соединения с банком. Система не знала, как обработать этот случай, и оставляла статус пустым.
Итог: За 20 минут SQL-запроса:
✅ Выявлен конкретный баг
✅ Спасена репутация продукта
✅ Дополнено ТЗ обработкой таймаутов
📈 Кейс 2: «Странные бонусы» — валидация бизнес-логики
Задача: После запуска программы лояльности маркетологи заметили, что бонусов начисляется больше, чем ожидалось.
Вместо того чтобы спрашивать «почему?», аналитик провёл анализ данных:
WITH user_orders AS (
SELECT
user_id,
COUNT(DISTINCT order_id) as order_count,
SUM(bonus_amount) as total_bonuses
FROM orders
WHERE created_at BETWEEN '2024-10-01' AND '2024-10-15'
GROUP BY user_id
)
SELECT
CASE
WHEN order_count = 1 THEN 'Один заказ'
WHEN order_count BETWEEN 2 AND 5 THEN '2-5 заказов'
ELSE 'Более 5 заказов'
END as segment,
COUNT(user_id) as users_count,
AVG(total_bonuses) as avg_bonus_per_user,
SUM(total_bonuses) as segment_bonus_total
FROM user_orders
GROUP BY 1
ORDER BY segment_bonus_total DESC;
Открытие: 70% всех бонусов получали пользователи с одним заказом, хотя по логике система должна была начислять больше постоянным клиентам.
Проблема: Ошибка в формуле расчёта — бонусы умножались на коэффициент новизны пользователя, а не на коэффициент лояльности.
Результат: SQL помог не просто найти ошибку, а количественно оценить её влияние на бизнес. 💰
🛠 Кейс 3: «Метрики для руководителя» — когда нужно быстро, но содержательно
Срочный запрос от CEO: «Как идут продажи в новом регионе?»
Вместо дня подготовки отчёта, аналитик за 30 минут сделал:
SELECT
DATE_TRUNC('week', order_date) as week,
region,
COUNT(order_id) as orders_count,
SUM(order_amount) as revenue,
COUNT(DISTINCT customer_id) as unique_customers,
SUM(order_amount) / COUNT(DISTINCT customer_id) as avg_revenue_per_customer
FROM sales
WHERE region = 'Сибирь'
AND order_date >= '2024-09-01'
GROUP BY 1, 2
ORDER BY week DESC;
Почему это эффективно?
Готовый анализ трендов по неделям
Ключевые метрики в одном месте
Инсайты для маркетинга — средний чек на клиента
Основа для принятия решений — стоит ли увеличивать инвестиции в регион
🎯 ВАШИ ДЕЙСТВИЯ НА ЗАВТРА:
Начните с малого: Освойте WHERE, GROUP BY, JOIN — этого хватит для 80% задач
Спрашивайте доступ к БД на проекте (только для чтения!)
Автоматизируйте рутину: Сохраняйте полезные запросы в saved queries
Изучайте оконные функции (OVER, PARTITION BY) — это следующий уровень
Запомните: SQL для аналитика — это не про «базы данных», это про понимание данных. Каждый запрос — это вопрос к системе, и правильный вопрос даёт правильный ответ. 🧠
#SQL
📊 SQL ДЛЯ СИСТЕМНОГО АНАЛИТИКА: КАК ЗАПРОСЫ ПОМОГАЮТ НАХОДИТЬ ПРОБЛЕМЫ БЫСТРЕЕ КОФЕ
Привет, коллеги! 👋
Многие думают, что SQL — это для разработчиков и администраторов баз данных. Но на самом деле SQL для аналитика — как микроскоп для биолога. Это инструмент, который позволяет увидеть реальную картину, проверить гипотезы и найти ошибки в требованиях ещё до того, как они уйдут в разработку. 🧐
Сегодня покажу на реальных кейсах, как простые SQL-запросы спасали проекты и помогали принимать правильные решения. Поехали! 🚀
🔍 КЕЙС 1: ДУБЛИКАТЫ, КОТОРЫХ НЕ ДОЛЖНО БЫТЬ
Ситуация:
На тестировании CRM-системы заметили, что некоторые клиенты получают по два одинаковых письма. Разработчики ищут баг в коде, тестировщики проверяют сценарии. Аналитик предлагает заглянуть в данные.
Запрос:
Результат:
Нашлось 342 записи с одинаковыми customer_id! Оказалось, при интеграции с внешней системой дублировались импорты из-за отсутствия уникального ключа.
Вывод:
Проблема была не в коде, а в процессе загрузки данных. Аналитик инициировал изменение интеграции и очистку дублей. Баг исчез до того, как разработчики начали искать его в логике приложения.
🎯 Что дал SQL:
Сэкономил неделю бесполезных поисков в коде и указал на реальную причину.
📉 КЕЙС 2: «НЕВОЗМОЖНЫЕ» СКИДКИ
Ситуация:
В интернет-магазине маркетологи запустили акцию: «Скидка 20% на второй товар в заказе». Через месяц финансисты заметили, что средний чек упал, а количество заказов не выросло.
Гипотеза:
Возможно, скидка применяется неправильно. Аналитик решил проверить на реальных данных.
Запрос:
Результат:
Нашлись заказы, где скидка составляла 70-80% от суммы! Причина: в коде скидка применялась к каждому товару, а не ко второму. Баг в бизнес-логике, заложенной в ТЗ, но никто не проверял данные.
Вывод:
SQL помог обнаружить ошибку в требованиях на ранних данных. Акцию приостановили, переписали логику, потери составили всего 2 дня вместо месяца убытков.
📈 КЕЙС 3: ПОЧЕМУ ОТЧЁТ ТОРМОЗИТ 40 МИНУТ
Ситуация:
Руководитель жалуется: ежедневный отчёт по продажам формируется 40 минут. Разработчики предлагают купить более мощный сервер. Аналитик просит показать запрос.
Исходный запрос (упрощённо):
Проблема:
Подзапросы выполняются для каждой строки — это миллионы обращений к таблицам.
Оптимизированный запрос:
Результат:
Время выполнения упало с 40 минут до 8 секунд. Никакого нового сервера не понадобилось.
Вывод:
Аналитик, понимающий SQL, спас компанию от ненужных трат на железо и сделал отчёт мгновенным.
💡 ИТОГ:
SQL для системного аналитика — это не просто «плюшка в резюме», а рабочий инструмент, который:
Экономит время команды
Спасает от ошибок в требованиях
Даёт факты вместо догадок
Повышает ваш профессиональный уровень
#SQL
Привет, коллеги! 👋
Многие думают, что SQL — это для разработчиков и администраторов баз данных. Но на самом деле SQL для аналитика — как микроскоп для биолога. Это инструмент, который позволяет увидеть реальную картину, проверить гипотезы и найти ошибки в требованиях ещё до того, как они уйдут в разработку. 🧐
Сегодня покажу на реальных кейсах, как простые SQL-запросы спасали проекты и помогали принимать правильные решения. Поехали! 🚀
🔍 КЕЙС 1: ДУБЛИКАТЫ, КОТОРЫХ НЕ ДОЛЖНО БЫТЬ
Ситуация:
На тестировании CRM-системы заметили, что некоторые клиенты получают по два одинаковых письма. Разработчики ищут баг в коде, тестировщики проверяют сценарии. Аналитик предлагает заглянуть в данные.
Запрос:
SELECT
customer_id,
email,
COUNT(*) as duplicate_count
FROM customers
GROUP BY customer_id, email
HAVING COUNT(*) > 1
ORDER BY duplicate_count DESC;
Результат:
Нашлось 342 записи с одинаковыми customer_id! Оказалось, при интеграции с внешней системой дублировались импорты из-за отсутствия уникального ключа.
Вывод:
Проблема была не в коде, а в процессе загрузки данных. Аналитик инициировал изменение интеграции и очистку дублей. Баг исчез до того, как разработчики начали искать его в логике приложения.
🎯 Что дал SQL:
Сэкономил неделю бесполезных поисков в коде и указал на реальную причину.
📉 КЕЙС 2: «НЕВОЗМОЖНЫЕ» СКИДКИ
Ситуация:
В интернет-магазине маркетологи запустили акцию: «Скидка 20% на второй товар в заказе». Через месяц финансисты заметили, что средний чек упал, а количество заказов не выросло.
Гипотеза:
Возможно, скидка применяется неправильно. Аналитик решил проверить на реальных данных.
Запрос:
SELECT
order_id,
SUM(item_price) as total_price,
SUM(discount_amount) as total_discount,
CASE
WHEN SUM(discount_amount) > SUM(item_price) * 0.3 THEN 'Подозрительно много'
WHEN SUM(discount_amount) = 0 THEN 'Без скидки'
ELSE 'Нормально'
END as discount_check
FROM order_items
WHERE order_date >= '2024-10-01'
GROUP BY order_id
HAVING SUM(discount_amount) > SUM(item_price) * 0.3
ORDER BY total_discount DESC;
Результат:
Нашлись заказы, где скидка составляла 70-80% от суммы! Причина: в коде скидка применялась к каждому товару, а не ко второму. Баг в бизнес-логике, заложенной в ТЗ, но никто не проверял данные.
Вывод:
SQL помог обнаружить ошибку в требованиях на ранних данных. Акцию приостановили, переписали логику, потери составили всего 2 дня вместо месяца убытков.
📈 КЕЙС 3: ПОЧЕМУ ОТЧЁТ ТОРМОЗИТ 40 МИНУТ
Ситуация:
Руководитель жалуется: ежедневный отчёт по продажам формируется 40 минут. Разработчики предлагают купить более мощный сервер. Аналитик просит показать запрос.
Исходный запрос (упрощённо):
SELECT
customer_id,
(SELECT COUNT(*) FROM orders o2 WHERE o2.customer_id = o1.customer_id) as total_orders,
(SELECT SUM(amount) FROM payments p WHERE p.order_id IN
(SELECT order_id FROM orders o3 WHERE o3.customer_id = o1.customer_id)
) as total_paid
FROM customers o1
WHERE created_at >= '2024-01-01';
Проблема:
Подзапросы выполняются для каждой строки — это миллионы обращений к таблицам.
Оптимизированный запрос:
SELECT
c.customer_id,
COUNT(DISTINCT o.order_id) as total_orders,
SUM(p.amount) as total_paid
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
LEFT JOIN payments p ON o.order_id = p.order_id
WHERE c.created_at >= '2024-01-01'
GROUP BY c.customer_id;
Результат:
Время выполнения упало с 40 минут до 8 секунд. Никакого нового сервера не понадобилось.
Вывод:
Аналитик, понимающий SQL, спас компанию от ненужных трат на железо и сделал отчёт мгновенным.
💡 ИТОГ:
SQL для системного аналитика — это не просто «плюшка в резюме», а рабочий инструмент, который:
Экономит время команды
Спасает от ошибок в требованиях
Даёт факты вместо догадок
Повышает ваш профессиональный уровень
#SQL
❤1👍1
📊 SQL ДЛЯ СИСТЕМНОГО АНАЛИТИКА: НЕ ПРОСТО ЗАПРОСЫ, А СУПЕРСИЛА
Привет, коллеги! 👋 Часто слышу: «SQL — это для разработчиков и DBA». На самом деле, SQL — один из главных инструментов аналитика. С его помощью вы можете:
проверять данные, не дожидаясь отчётов;
находить баги быстрее, чем разработчики;
отвечать на вопросы бизнеса за 5 минут.
Сегодня покажу на реальных кейсах, как SQL спасает проекты. 🚀
📌 Кейс 1: «Где мои бонусы?» (проверка гипотезы)
Менеджер жалуется: «Клиенты не получают бонусы за регистрацию!». Разработчики говорят: «Всё работает, проверяли». Вы решаете проверить сами.
Пишете запрос в базу:
Результат: бонусы получают только 30% пользователей, хотя должны все. Баг найден за 2 минуты — разработчик ошибся в условии начисления. Вы сэкономили день споров. ✅
📌 Кейс 2: «Аномалия в продажах» (обнаружение бага)
Бизнес заметил: вчера продажи упали на 20%. Начинается паника. Вы идёте в базу и смотрите динамику по часам:
Обнаруживаете, что провал пришёлся на 14:00–15:00 — именно в это время выкатывали новую версию. Дальше — запрос по конкретному виду товаров:
Выясняется: пропали заказы из категории «Электроника». Оказывается, разработчики задефили изменения в прайсе для этой категории. Без SQL вы бы искали проблему часами. ⏱️
📌 Кейс 3: «Тестовые данные для приёмки» (помощь тестировщикам)
QA нужно проверить сценарий «пользователь с 10 заказами». Вы пишете запрос, который выгружает подходящих пользователей:
Тестировщики получают готовый список реальных пользователей (или их id) и могут быстро проверить сценарий. Никакого ручного подбора данных. 🧪
📌 Кейс 4: «Массовое обновление» (подготовка данных)
Нужно проставить признак «VIP» всем клиентам, у которых сумма покупок > 1 млн. Вместо ручного обновления пишете запрос:
10 секунд — и задача решена. Безопасно, быстро, без ошибок. 🔥
🎯 ЧТО ДАЁТ SQL АНАЛИТИКУ?
Независимость — вы не ждёте отчёты от разработчиков.
Скорость — ответы на вопросы бизнеса за минуты.
Глубина — можете проверить данные на любом уровне детализации.
Доверие — ваши выводы подкреплены фактами, а не догадками.
📚 С ЧЕГО НАЧАТЬ?
Освойте SELECT, WHERE, GROUP BY, JOIN — этого хватит для 80% задач.
Изучите оконные функции (ROW_NUMBER(), LAG()) — они выводят анализ на новый уровень.
Практикуйтесь на учебных базах или в своём проекте (с доступом только на чтение!).
Помните: SQL — это не просто язык запросов, а ваш главный помощник в расследованиях. Чем лучше вы им владеете, тем больше инсайтов можете дать команде.💪
#SQL
Привет, коллеги! 👋 Часто слышу: «SQL — это для разработчиков и DBA». На самом деле, SQL — один из главных инструментов аналитика. С его помощью вы можете:
проверять данные, не дожидаясь отчётов;
находить баги быстрее, чем разработчики;
отвечать на вопросы бизнеса за 5 минут.
Сегодня покажу на реальных кейсах, как SQL спасает проекты. 🚀
📌 Кейс 1: «Где мои бонусы?» (проверка гипотезы)
Менеджер жалуется: «Клиенты не получают бонусы за регистрацию!». Разработчики говорят: «Всё работает, проверяли». Вы решаете проверить сами.
Пишете запрос в базу:
SELECT
DATE(created_at) as reg_date,
COUNT(user_id) as total_users,
COUNT(bonus_id) as users_with_bonus,
ROUND(COUNT(bonus_id) * 100.0 / COUNT(user_id), 2) as percent
FROM users
LEFT JOIN bonuses ON users.user_id = bonuses.user_id
WHERE created_at >= '2024-10-01'
GROUP BY reg_date
ORDER BY reg_date;
Результат: бонусы получают только 30% пользователей, хотя должны все. Баг найден за 2 минуты — разработчик ошибся в условии начисления. Вы сэкономили день споров. ✅
📌 Кейс 2: «Аномалия в продажах» (обнаружение бага)
Бизнес заметил: вчера продажи упали на 20%. Начинается паника. Вы идёте в базу и смотрите динамику по часам:
SELECT
DATE_TRUNC('hour', order_time) as hour,
COUNT(order_id) as orders,
SUM(amount) as revenue
FROM orders
WHERE order_time >= CURRENT_DATE - INTERVAL '2 days'
GROUP BY hour
ORDER BY hour;
Обнаруживаете, что провал пришёлся на 14:00–15:00 — именно в это время выкатывали новую версию. Дальше — запрос по конкретному виду товаров:
SELECT
product_category,
COUNT(order_id) as orders
FROM orders
WHERE order_time BETWEEN '2024-10-15 14:00' AND '2024-10-15 15:00'
GROUP BY product_category;
Выясняется: пропали заказы из категории «Электроника». Оказывается, разработчики задефили изменения в прайсе для этой категории. Без SQL вы бы искали проблему часами. ⏱️
📌 Кейс 3: «Тестовые данные для приёмки» (помощь тестировщикам)
QA нужно проверить сценарий «пользователь с 10 заказами». Вы пишете запрос, который выгружает подходящих пользователей:
SELECT
user_id,
COUNT(order_id) as order_count,
SUM(amount) as total_spent
FROM orders
GROUP BY user_id
HAVING COUNT(order_id) >= 10
ORDER BY order_count DESC
LIMIT 20;
Тестировщики получают готовый список реальных пользователей (или их id) и могут быстро проверить сценарий. Никакого ручного подбора данных. 🧪
📌 Кейс 4: «Массовое обновление» (подготовка данных)
Нужно проставить признак «VIP» всем клиентам, у которых сумма покупок > 1 млн. Вместо ручного обновления пишете запрос:
UPDATE customers
SET is_vip = TRUE
WHERE customer_id IN (
SELECT customer_id
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 1000000
);
10 секунд — и задача решена. Безопасно, быстро, без ошибок. 🔥
🎯 ЧТО ДАЁТ SQL АНАЛИТИКУ?
Независимость — вы не ждёте отчёты от разработчиков.
Скорость — ответы на вопросы бизнеса за минуты.
Глубина — можете проверить данные на любом уровне детализации.
Доверие — ваши выводы подкреплены фактами, а не догадками.
📚 С ЧЕГО НАЧАТЬ?
Освойте SELECT, WHERE, GROUP BY, JOIN — этого хватит для 80% задач.
Изучите оконные функции (ROW_NUMBER(), LAG()) — они выводят анализ на новый уровень.
Практикуйтесь на учебных базах или в своём проекте (с доступом только на чтение!).
Помните: SQL — это не просто язык запросов, а ваш главный помощник в расследованиях. Чем лучше вы им владеете, тем больше инсайтов можете дать команде.
#SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
📊 SQL ДЛЯ АНАЛИТИКА: ОКОННЫЕ ФУНКЦИИ — СЛЕДУЮЩИЙ УРОВЕНЬ
Привет, коллеги! 👋 Вы уже знаете SELECT, JOIN и GROUP BY. Но есть вещь, которая выводит анализ на новый уровень — оконные функции. Они позволяют считать скользящие средние, приросты, доли и ранги без сложных подзапросов. Сегодня разберём на реальных задачах. Поехали! 🚀
📌 Кейс 1: Сравнение продаж с прошлым месяцем (LAG)
Менеджер просит: «Покажи помесячную динамику и прирост к прошлому месяцу». Без оконных функций пришлось бы делать self-join или подзапрос. А так:
Что получим: месячная выручка, прошлая выручка и процент роста. Всё одним запросом! 🔥
📌 Кейс 2: Топ-3 товара в каждой категории (ROW_NUMBER)
Нужно для каждой категории выделить три самых продаваемых товара. Раньше — муть с подзапросами. Теперь:
Результат: аккуратный топ по каждой категории. А если нужны все товары с повторами (если продажи одинаковые) — используйте RANK() или DENSE_RANK(). 🏆
📌 Кейс 3: Скользящее среднее за 7 дней (AVG OVER)
Для отчёта по трендам нужно сгладить дневные скачки. Скользящее среднее — идеально:
Теперь видно тенденцию без шума. Маркетологи будут благодарны! 📈
📌 Кейс 4: Доля товара в общей выручке (SUM OVER)
ABC-анализ: надо понять, какие товары дают 80% выручки. Считаем долю накопленным итогом:
Видим, где граница 80%. Классика для категорийных менеджеров. 📦
🎯 ПОЧЕМУ ЭТО ВАЖНО ДЛЯ АНАЛИТИКА?
Скорость: один запрос вместо трёх.
Гибкость: можно комбинировать с группировками и фильтрами.
Точность: меньше шансов ошибиться в логике.
Освойте оконные функции — и бизнес будет носить вас на руках за быстрые и точные ответы. 💪
#SQL
Привет, коллеги! 👋 Вы уже знаете SELECT, JOIN и GROUP BY. Но есть вещь, которая выводит анализ на новый уровень — оконные функции. Они позволяют считать скользящие средние, приросты, доли и ранги без сложных подзапросов. Сегодня разберём на реальных задачах. Поехали! 🚀
📌 Кейс 1: Сравнение продаж с прошлым месяцем (LAG)
Менеджер просит: «Покажи помесячную динамику и прирост к прошлому месяцу». Без оконных функций пришлось бы делать self-join или подзапрос. А так:
SELECT
DATE_TRUNC('month', order_date) as month,
SUM(amount) as revenue,
LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) as prev_revenue,
(SUM(amount) - LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date))) /
LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) * 100 as growth_percent
FROM orders
GROUP BY month
ORDER BY month;
Что получим: месячная выручка, прошлая выручка и процент роста. Всё одним запросом! 🔥
📌 Кейс 2: Топ-3 товара в каждой категории (ROW_NUMBER)
Нужно для каждой категории выделить три самых продаваемых товара. Раньше — муть с подзапросами. Теперь:
WITH ranked_products AS (
SELECT
category_id,
product_id,
SUM(quantity) as total_sold,
ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY SUM(quantity) DESC) as rn
FROM order_items
GROUP BY category_id, product_id
)
SELECT category_id, product_id, total_sold
FROM ranked_products
WHERE rn <= 3;
Результат: аккуратный топ по каждой категории. А если нужны все товары с повторами (если продажи одинаковые) — используйте RANK() или DENSE_RANK(). 🏆
📌 Кейс 3: Скользящее среднее за 7 дней (AVG OVER)
Для отчёта по трендам нужно сгладить дневные скачки. Скользящее среднее — идеально:
SELECT
date,
revenue,
AVG(revenue) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as avg_7d
FROM daily_revenue
ORDER BY date;
Теперь видно тенденцию без шума. Маркетологи будут благодарны! 📈
📌 Кейс 4: Доля товара в общей выручке (SUM OVER)
ABC-анализ: надо понять, какие товары дают 80% выручки. Считаем долю накопленным итогом:
WITH product_revenue AS (
SELECT
product_id,
SUM(amount) as revenue,
SUM(SUM(amount)) OVER () as total_revenue
FROM sales
GROUP BY product_id
)
SELECT
product_id,
revenue,
revenue / total_revenue * 100 as percent,
SUM(revenue / total_revenue * 100) OVER (ORDER BY revenue DESC) as cumulative_percent
FROM product_revenue
ORDER BY revenue DESC;
Видим, где граница 80%. Классика для категорийных менеджеров. 📦
🎯 ПОЧЕМУ ЭТО ВАЖНО ДЛЯ АНАЛИТИКА?
Скорость: один запрос вместо трёх.
Гибкость: можно комбинировать с группировками и фильтрами.
Точность: меньше шансов ошибиться в логике.
Освойте оконные функции — и бизнес будет носить вас на руках за быстрые и точные ответы. 💪
#SQL