SELECT COUNT(*) FROM orders;

Считает все строки, независимо от того, есть ли там NULL.
В нашем примере результат: 4.

SELECT COUNT(user_id) FROM orders;

Считает только те строки, где user_id не NULL.
У столбца user_id есть одно значения NULL, оно не попадает в подсчёт.
Результат: 3.

SELECT COUNT(DISTINCT user_id FROM orders;

Считает только уникальные значения user_id, и при этом игнорирует NULL.
В нашем примере уникальные user_id → 10, 11 результат: 2.

COUNT(*) → сколько всего строк в таблице.

COUNT(col) → сколько не-NULL значений в столбце.

COUNT(DISTINCT col) → сколько уникальных значений.

Специалист по анализу и визуализации данных, который помогает бизнесу принимать решения на основе отчётов и выявленных тенденций.
Работает с SQL, Excel, Power BI, Tableau.
В 2025 году — одна из самых востребованных ролей в РФ и Европе, особенно в BI, продуктовых компаниях и финансах. Часто совмещает функции бизнес-аналитика.

Что делает:

- строит дашборды и отчёты;
- анализирует данные и ищет закономерности;
- отвечает на вопрос «что произошло и почему».

Создаёт и поддерживает инфраструктуру данных: хранилища, пайплайны, очереди, системы обработки.
Ориентирован на масштабируемость, качество и надёжность передачи данных.
Инструменты — Python, SQL, Spark, Airflow, облака. Востребован в IT, финтехе, медицине, e-commerce.

Что делает:

- проектирует хранилища и Data Lake;
- строит ETL/ELT-пайплайны;
- обеспечивает доступность и качество данных.

Администратор баз данных — специалист, отвечающий за работоспособность, безопасность и производительность систем хранения данных. Занимается резервированием, мониторингом, настройкой и эксплуатацией системами управления базами данных (СУБД).

Популярная и классическая роль, в 2025 всё чаще совмещается с инженерными функциями: DevOps-подход, автоматизация, инфраструктурный код.

Что делает:

- настраивает СУБД, репликацию, резервное копирование;
- следит за производительностью;
- обеспечивает отказоустойчивость и безопасность.

Строит модели, применяет машинное обучение и статистику для прогнозов, оптимизаций и автоматизации решений. Работает с Python, R, ML/AI-фреймворками, большими и разнородными данными.
Востребован в рекомендательных системах, финтехе, медицине, производстве, AI-разработке.

Что делает:

- создаёт ML-модели;
- анализирует данные на глубоком уровне;
- отвечает на вопросы «что будет» и «что стоит сделать».

Data Analyst — поясняет бизнесу, что происходит в данных.
Data Engineer — делает данные доступными и надёжными.
DBA — следит, чтобы СУБД работала быстро и безопасно.
Data Scientist — строит алгоритмы и прогнозы.

Каждая роль закрывает свою часть работы — вместе они формируют полный цикл работы с данными.

SELECT u.name, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.amount > 150;

Что происходит:

INNER JOIN оставляет только строки, где есть заказы, совершенные клиентами.
WHERE фильтрует только реальные строки заказов стоимостью более 150.

📊 Результат:
name  amount

Anna  200
Bob   300

Kate исчезает уже на этапе JOIN.

SELECT u.name, o.amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.amount > 150;

Что происходит:

LEFT JOIN создаёт такие строки:

| name  | amount    |
|-----—-|-------——--|
| Anna  | 100       |
| Anna  | 200       |
| Bob   | 300       |
| Kate  | NULL      |

WHERE применяет фильтр:

o.amount > 150


NULL > 150 = UNKNOWN → строка отбрасывается.

📊 Результат:

name  amount

Anna  200
Bob   300

Kate исчезла, потому что WHERE удаляет строки с NULL.
LEFT JOIN превратился в INNER JOIN.

SELECT u.name, o.amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id AND o.amount > 150;

Что происходит:

Фильтрация происходит во время JOIN, а не после него.
LEFT JOIN сохраняет всех пользователей из таблицы users (левая таблица) и присоединяет к ней строки из таблицы orders (правая таблица) предварительно отфильтрованные по условию amount > 150.


📊 Результат:

name  amount

Anna  200
Bob   300
Kate  NULL

В данном случае LEFT JOIN ничего не потерял.

Но хорошая новость в том:
Что ты не один.
Мы все это проходили — и выживали 😉

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

Большинство бизнес-приложений — от финансовых систем до аналитических платформ — работают на реляционных СУБД. PostgreSQL, MySQL, SQL Server, Oracle и другие остаются основой инфраструктуры компаний. Это делает SQL жизненно важным для разработки и анализа.

Реляционные модели и ACID-гарантии обеспечивают высокую надёжность, согласованность и устойчивость данных. Многие проекты, особенно критичные для бизнеса, не могут позволить себе слабые гарантии или непредсказуемые схемы данных.

От простых выборок до сложных агрегаций, оконных функций и CTE — SQL прекрасно решает аналитические запросы. Многие современные инструменты, включая BigQuery, Snowflake и Spark SQL, расширяют SQL, а не заменяют его.

Современные СУБД добавляют новые возможности: работу с JSON, расширенные типы данных, функции машинного обучения и гибридные модели хранения. SQL не стоит на месте — он адаптируется.

SQL остаётся ключевым языком для работы с данными благодаря своей зрелости, универсальности и устойчивости. Он доказал свою эффективность временем, а современная индустрия только укрепляет его позиции.

Условная компания:

- 9 сотрудников получают по 70 000 ₽
- Директор получает 1 000 000 ₽
- (9 * 70000 + 1 * 1000000) / 10 = 163 000
- Средняя зарплата: 163 000 ₽.

Кажется, будто все живут прекрасно.
Но это совсем не так — большинство получает в 2 раза меньше, чем “средний показатель”.

Вот почему в экономике среднее так часто критикуют — оно скрывает реальные условия людей.

Представьте магазин:

- 90 клиентов тратят по 500 ₽;
- 10 клиентов — по 15 000 ₽ (редкие, но жирные покупки).
- (90 * 500 + 10 * 15000) / 100 = 1950
- Маркетолог пишет в отчёте: «Средний чек — почти 2 000 ₽, всё отлично!»

Но если:

эти 10 «жирных» клиентов уйдут — средний чек рухнет до 500 ₽;

Допустим, вы анализируете время отклика сервера.

- Среднее время: 200 мс
- Но если внутри есть такие значения, как 50 мс, 60 мс… и внезапно 3000 мс, то среднее будет “приличным”, а пользователи всё равно будут жаловаться на лаги.

Поэтому часто смотрят 95-й и 99-й перцентиль, а не среднее.

В зависимости от задачи — разные метрики:

Медиана — лучше показывает “типичное” значение
Мода — самое частое значение
Перцентили — помогают увидеть хвосты распределения
Разброс (дисперсия, стандартное отклонение) — показывает, насколько данные “раскиданы”

Среднее — это всего лишь одна точка,
и без контекста она легко вводит в заблуждение.