Как часто используешь SQL в работе?

Как часто используешь SQL в работе

SQL — это не опциональный скилл для BA, это необходимость. Я пользуюсь SQL практически ежедневно, и вот почему это так важно и как я его применяю.

Почему BA должен знать SQL

1. Независимость в анализе Вместо того, чтобы просить разработчика "дай мне отчёт по активным пользователям", я сам пишу запрос и получаю ответ за 2 минуты. Не нужно ждать в очереди.

2. Проверка данных Когда я пишу требование, я должен понимать:

• Какие данные у нас есть в системе?
• Насколько они качественные?
• Есть ли дубликаты или пропуски?

Это невозможно проверить без SQL.

3. Валидация требований Иногда я пишу требование, а потом спрашиваю: "А эти данные вообще у нас есть?" SQL помогает найти ответ.

4. Общий язык с разработчиками Когда я говорю разработчику: "добавь индекс на (user_id, created_at)", он понимает, что я знаю, о чём говорю. Уважение + доверие.

Как я использую SQL в разных ситуациях

Ситуация 1: Анализ пользователей

Вопрос: Сколько активных пользователей было на этой неделе?

SELECT COUNT(DISTINCT user_id) as active_users
FROM events
WHERE event_type = 'page_view'
AND created_at >= NOW() - INTERVAL '7 days'
AND created_at < NOW();

Результат: 5000 активных пользователей. На основе этого я говорю Product Manager: "Растём на 10% в неделю".

Ситуация 2: Проверка качества данных

Вопрос: Есть ли пропущенные email в таблице users?

SELECT COUNT(*) as users_with_null_email
FROM users
WHERE email IS NULL;

Результат: 50 пользователей без email. Это проблема, нужно разбираться.

Дальше я углубляюсь:

SELECT 
    CASE 
        WHEN email IS NULL THEN 'No email'
        WHEN email = '' THEN 'Empty string'
        ELSE 'Valid email'
    END as email_status,
    COUNT(*) as count
FROM users
GROUP BY email_status;

Нахожу, что 30 пользователей имеют пустую строку вместо NULL. Это баг в коде регистрации. Требование: исправить валидацию.

Ситуация 3: Расчёт метрик

Вопрос: Какой процент пользователей вернулся через неделю? (Retention rate)

WITH first_users AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE created_at >= '2026-03-15' AND created_at < '2026-03-16'
),
returning_users AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE created_at >= '2026-03-22' AND created_at < '2026-03-23'
)
SELECT 
    COUNT(DISTINCT fu.user_id) as new_users,
    COUNT(DISTINCT ru.user_id) as returning_users,
    ROUND(100.0 * COUNT(DISTINCT ru.user_id) / COUNT(DISTINCT fu.user_id), 2) as retention_percent
FROM first_users fu
LEFT JOIN returning_users ru ON fu.user_id = ru.user_id;

Результат: 40% retention за неделю. Это приемлемо для SaaS, но есть место для улучшения.

Ситуация 4: Поиск проблем

Вопрос: Почему bounce rate скакнул с 30% на 45% вчера?

Сначала я проверяю:

• Изменилась ли структура трафика?
• Приходят ли пользователи из других источников?
• Используют ли они другие браузеры или устройства?

SELECT 
    DATE(created_at) as date,
    source as traffic_source,
    COUNT(DISTINCT session_id) as sessions,
    COUNT(CASE WHEN bounce = true THEN 1 END) as bounces,
    ROUND(100.0 * COUNT(CASE WHEN bounce = true THEN 1 END) / COUNT(DISTINCT session_id), 2) as bounce_rate
FROM sessions
WHERE created_at >= NOW() - INTERVAL '3 days'
GROUP BY DATE(created_at), source
ORDER BY date DESC, bounce_rate DESC;

Нахожу: вчера много трафика из рекламной кампании с плохо таргетированной аудиторией. Вывод: улучшить параметры рекламной кампании или создать отдельный landing page.

Ситуация 5: Валидация требования перед разработкой

Требование: Показать топ-5 продуктов по продажам за последний месяц

Перед тем, как отправить разработчику, я проверяю:

• Достаточно ли у нас данных о продажах?
• Как распределены продажи (может быть, топ-1 продукт занимает 80% и остальные 4 бесполезны)?
• Какой период конкретно?

SELECT 
    product_id,
    product_name,
    COUNT(DISTINCT order_id) as orders,
    SUM(amount) as revenue,
    ROUND(100.0 * SUM(amount) / SUM(SUM(amount)) OVER (), 2) as percent_of_total
FROM orders
WHERE created_at >= DATE_TRUNC('month', NOW()) - INTERVAL '1 month'
AND created_at < DATE_TRUNC('month', NOW())
GROUP BY product_id, product_name
ORDER BY revenue DESC
LIMIT 5;

Исходя из результатов я могу уточнить требование: может быть, нужна фильтрация по категориям или временному диапазону.

Мой уровень SQL

Я не пишу сложные запросы с рекурсивными CTE и оконными функциями каждый день, но знаю их.

Что я регулярно используюю:

• SELECT, WHERE, GROUP BY, ORDER BY
• JOIN (INNER, LEFT, RIGHT)
• Агрегирующие функции (COUNT, SUM, AVG, MIN, MAX)
• Условия (CASE WHEN)
• Подзапросы и CTE (WITH)
• Функции для работы с датами и строками

Что использую реже, но знаю:

• Оконные функции (ROW_NUMBER, RANK, LAG, LEAD)
• Рекурсивные CTE
• HAVING для фильтрации после GROUP BY
• DISTINCT и UNION
• LIMIT, OFFSET
• Индексы и EXPLAIN ANALYZE

Что я не использую:

• Сложные триггеры (это работа DBA)
• Процедуры и функции на PL/SQL (это работа разработчика БД)
• Очень сложные аналитические запросы (для этого есть BI специалисты)

Где я учусь SQL

Есть SQL запросы, которые я пишу в голове, а есть — гугли.

Мой подход к новым запросам:

1. Четко сформулирую, что мне нужно
2. Напишу черновик (может быть неправильно)
3. Протестирую на staging среде
4. Если ошибка — смотрю error message и исправляю
5. Если сложный запрос — просю код review у разработчика

Когда я не трогаю SQL

Есть вещи, которые я делегирую разработчикам:

• Оптимизация performance (они знают лучше)
• Изменение схемы БД (может сломать production)
• Сложные миграции (нужна транзакция и откат)

Если я понимаю, что мне нужен сложный запрос → я описываю, что мне нужно, а разработчик или DBA пишет запрос.

Как SQL помогает в требованиях

Пример 1: Требование "Показать среднюю стоимость заказа" Чтобы это написать, я должен понимать:

• Как считается стоимость (с налогом или без)?
• Какие заказы включаются (только завершённые? включая отменённые)?
• За какой период?

SQL помогает мне ответить на эти вопросы до написания требования.

Пример 2: Требование "Автоматически отправлять письмо неактивным пользователям" Перед тем, как писать требование, я должен узнать:

• Сколько таких пользователей?
• Нет ли ошибки в определении неактивности?

SELECT COUNT(DISTINCT user_id) as inactive_users
FROM users
WHERE last_activity < NOW() - INTERVAL '30 days';

Результат: 5000 пользователей. Большая кампания, нужно тестировать.

Трудные моменты

Проблема: Иногда я пишу неправильный запрос и не замечаю

Решение:

• Всегда проверяю результат на здравый смысл
• Если число кажется странным (например, 999999 users), перепроверяю
• Просю code review у разработчика для сложных запросов

Проблема: Запрос работает 30 минут и не заканчивается

Решение:

• Добавляю LIMIT 100 для быстрой проверки
• Использую EXPLAIN ANALYZE, чтобы понять, где узкое место
• Просю DBA помочь с индексами

Вывод

SQL — это не "nice to have" для BA, это инструмент, как Excel. Я пишу запросы 2-3 раза в день:

• Проверяю данные (утром)
• Анализирую метрики (днём)
• Ищу проблемы в данных (когда нужно)

Не нужно быть экспертом в SQL, но нужно уметь писать простые и средние запросы. И если я не знаю, как что-то сделать — я гугли и учусь.