💥 Задачи с собеседования по SQL для аналитиков 💥


Сегодня в 19:00 Мск проведём продвинутую практику по БД+SQL, где разберём задачи уровня Middle+ / Senior, которые встречаются и в работе, и на собеседованиях.

💥 SQL-запросы с JOIN на реальной БД через DBeaver
🔗 Подробности и запись
Стоимость участия от 1 650 рублей

✅ Запись будет доступна в платформе
🎁 Бонус: занятие в записи "Маппинг данных: БД и JSON"



А пока — задача для самопроверки 👇
По ней сразу видно, насколько уверенно вы чувствуете себя в SQL (JOIN-ах):
👍 решите быстро - вы в форме,
🧐 зависнете - значит на практике будет максимум пользы.


Задача:

В системе Интернет-магазина есть таблицы:
▫️ user (id, firstname, lastname, phone)
▫️ order (id, number, user_id, created_at)
▫️ product (id, name, price)
▫️ order_product (order_id, product_id, amount, sale_price)

Нужно написать SQL-запрос, который вернёт список заказов, где:
▫️ более 5 продуктов,
▫️ общая стоимость более 5 000 рублей.

В результате вывести:
+ номер заказа,
+ количество товаров,
+ имя пользователя-покупателя,
+ телефон покупателя,
+ полную стоимость заказа.

Ответ 🔽
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

SELECT
    o.number AS order_number,
    SUM(op.amount) AS items_count,
    CONCAT(u.firstname, ' ', u.lastname) AS customer_name,
    u.phone AS customer_phone,
    SUM(op.amount * COALESCE(op.sale_price, p.price)) AS total_price
FROM "order" o
JOIN "user" u
  ON u.id = o.user_id
JOIN order_product op
  ON op.order_id = o.id
JOIN product p
  ON p.id = op.product_id
GROUP BY
    o.id, o.number, u.firstname, u.lastname, u.phone
HAVING
    SUM(op.amount) > 5
    AND SUM(op.amount * COALESCE(op.sale_price, p.price)) > 5000
ORDER BY total_price DESC;

Какие ещё интересные задачи по SQL недавно встречали на собесах?
Делитесь в комментариях ✍️

🎯 Чек-лист навыков Системного Аналитика: полная и актуальная версия 2026 🎯

В начале года я собрала полный список навыков, которые чаще всего ждут от системного аналитика в 2026 — от требований и БД до интеграций, API и архитектуры.

Посты:
🔗 Часть 1
🔗 Часть 2
🔗 Часть 3 - инструменты


А теперь - самое полезное 👇
Я собрала всё это в одну статью и добавила:
▫️ маркировку навыков по уровням (junior / middle / senior)
▫️ формулу, как оценить свой грейд

🔗 Ссылка на статью


Чтобы было удобно собрать личный план развития, мы сделали PDF-чек-лист.
Можно скачать, распечатать и отмечать прогресс — или просто сделать скрины и отмечать прямо на них.
📄 [PDF прикреплён к посту]


👉 Рекомендации:
1. Пройдите по чек-листу и отметьте свои навыки.
2. Выберите по 2-3 навыка на каждый месяц 2026 года к освоению.
3. Через год перепроверьте себя: что нового выучили.


Сохраняйте в избранное и оценивайте свой грейд — это та штука, к которой реально полезно возвращаться весь год 🚀


Подписывайтесь на @getanalysts, чтобы быть в курсе самых актуальных новостей для БА и СА 🚀

📚 Практическое руководство по исследованию OAuth 2.0 в Mail ru 📚


Как разобраться с OAuth 2.0?
Только на реальной практике 💻

Пройдите один из ключевых Flow для OAuth 2.0 через Postman, на примере интеграции с OAuth 2.0 сервером от Mail ru.

Интеграция с сервером OAuth 2.0 от Mail ru нужна, чтобы сделать кнопки в приложении:
+ "Войти через аккаунт Mail ru"
+ "Зарегистрироваться через аккаунт Mail ru".


👉 Результат работы по руководству:
1. Поймёте полную последовательность шагов OAuth 2.0 (Grant Type = Authorization Code)
2. Разберётесь, чем отличаются access token и refresh token
3. Поймёте, где и как токены использовать при вызове API
4. Чётко увидите, когда токен получать, как долго хранить и когда обновлять


🔖 Сохраняйте руководство и повторяйте шаги в Postman — это самый быстрый способ реально разобраться с OAuth.


Больше по OAuth 2.0:
#FoodDeliveryGA_oauth
#ИнтеграцииGA

✅ 42 API-термина, которые спрашивают СА на собеседовании: чек-лист ✅

👉 Ключевые:
1. API (Application Programming Interface)
2. REST API (Representational State Transfer)
3. HTTP-методы запросов
4. Эндпоинты
5. Коды ответов
6. Ограничение частоты запросов (Rate Limiting)
7. Полезная нагрузка (Payload)
8. Заголовки (Headers)
9. Аутентификация
10. Авторизация
11. Пагинация
12. Кэширование


👉 Дополнительно:
1. OAuth
2. JWT Token
3. API Gateway
4. API Keys
5. Basic Authentication
6. Bearer Tokens
7. CORS
8. Webhooks
9. OpenAPI
10. API Versioning (Версионирование API)
11. Content Negotiation
12. Query Parameters
13. Path Parameters
14. API Documentation
15. API Monitoring
16. Throttling
17. Circuit Breaker
18. Idempotency (Идемпотентность)
19. API Proxy
20. Retry Logic (Логика ретраев / повторов)
21. Batch Processing (Пакетная обработка)
22. API Security
23. Health Checks
24. API Testing
25. Mock APIs
26. API Marketplace
27. API Schema
28. Semantic Versioning (Семантическое версионирование)
29. Hypermedia
30. API Deprecation (Устаревание API)


Всё самое важное и нужное в одном месте 😎

#RestApiGA

🔑 "Войти через Госуслуги / Google / Mail ru": пример постановки задачи на OAuth 2.0 интеграцию 🔖

Сегодня одна из самых популярных задач — подключить единый аккаунт для входа во все приложения: “через Госуслуги”, “через Google” и т.д.

Я показываю подход на примере Mail.ru OAuth 2.0, потому что:
✔️ документация на русском (в отличие от Google),
✔️ можно быстро создать тестовое приложение и прогнать сценарий в Postman руками (в отличие от Госуслуг),
✔️ на нём удобно разобрать нюансы, которые потом повторяются и для других провайдеров.


Я подготовила:
👉 шаблон постановки задачи: “Первичная регистрация аккаунта через ‘Войти c Mail.ru’”.
Это интеграционный Use Case.


На что важно обратить внимание:

◽️ 1) Токен Mail.ru — не “токен вашей системы”
В этом сценарии access_token Mail.ru нужен только, чтобы один раз получить базовые данные профиля и создать пользователя.
Дальше пользователь должен работать на внутренней авторизации FoodDeliveryGA (в примере — Bearer Token на 30 дней).
Внутренняя авторизация может быть тоже OAuth 2.0, а может отличаться, как в примере, и быть более простой.


◽️ 2) Есть внешние методы OAuth и внутренние методы вашей авторизации
В постановке чётко разделены:
+ внешние вызовы (Mail.ru OAuth + REST API),
+ внутренние API FoodDeliveryGA (/auth/mailru/authorize, /auth/mailru/token).


◽️ 3) Flow “через code”, а не “токен сразу на фронт”
Показан безопасный вариант OAuth 2.0:
Frontend получает code, а токены внешнего провайдера получает уже Backend.
Это стандарт для продуктовых решений.

◽️ 4) Декомпозиция задачи важна
В примере только Use Case авторизации, а по факту нужно делать:
+ первичную регистрацию
+ привязку акканта Mail.ru к существующей учетке
+ вход в аккаунт (очередная авторизация)
+ проверка доступа хотя бы раз в 24 часа (что токен не отозвали и не сменили)
+ деавторизация.


📌 Шаблон можно использовать как основу для постановок задач для “Войти через Google / Госуслуги” — меняется провайдер и детали API, но структура постановки задачи остаётся такой же.


Документ точно пригодитя 🔖🤝
Сохраните — это шаблон, который закрывает 80% типовых вопросов по OAuth.


#FoodDeliveryGA_oauth
#ИнтеграцииGA

⏯ ЭПИЗОД 39:
Всё про WebSocket: что это, где используют и зачем он в архитектуре

WebSocket встречается всё чаще. И понимать его хотя бы на базовом уровне становится важно.

Там, где есть чаты, одновременная работа пользователей и любые обновления в реальном времени, WebSocket API появляется очень быстро 💬

Подробно рассказываем про WebSocket в новом выпуске подкаста GetAnalyst:

🔗 Сайт эпизода с шаблоном задачи на WebSocket API


Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Сообщество системных аналитиков GetAnalyst — опыт здесь 📍