🍀BitBitGo🍀 Системный Анализ
3.22K subscribers
217 photos
153 videos
112 links
Курс «Системный анализ»
https://bitbitgo.by/
Пишем про системный анализ.
Поможем стартануть в карьере IT. Присоединяйся!
Download Telegram
🔍 🔤🔤🔤 🔤 🔤🔤🔤🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤 🔤🔤🔤🔤🔤🔤 🟰🔤🔤🔤🔤 🔤🔤🔤🔤🔤🔤🔤

Системный аналитик без 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 и агрегатные функции: Считать и обобщать
Для анализа и отчетов без этого никуда.

-- Посчитать выручку и средний чек по каждому городу
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: Идеальный сценарий (как мы задумывали) 🌟

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 помог обнаружить баг в ТЗ

Ситуация: В платёжной системе после релиза новой фичи часть транзакций «терялась». Разработчики клялись, что всё работает. Поддержка завалена жалобами.

Что сделал аналитик? Вместо долгих совещаний, написал исследовательский запрос:

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-системы заметили, что некоторые клиенты получают по два одинаковых письма. Разработчики ищут баг в коде, тестировщики проверяют сценарии. Аналитик предлагает заглянуть в данные.

Запрос:

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: «Где мои бонусы?» (проверка гипотезы)

Менеджер жалуется: «Клиенты не получают бонусы за регистрацию!». Разработчики говорят: «Всё работает, проверяли». Вы решаете проверить сами.

Пишете запрос в базу:

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 или подзапрос. А так:

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