💼 5 навыков, кроме SQL, которые сегодня ищут работодатели

Российский рынок труда переживает кадровый дефицит:
безработица в октябре 2025 года составляет всего 2–3 % — исторический минимум. Компании конкурируют за специалистов, особенно в IT, инженерии и аналитике.

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

🔹 1. Python и автоматизация анализа данных

Python стал стандартом для аналитиков в России —
почти половина вакансий включает его в обязательные навыки.
Также востребованы R, pandas, NumPy и библиотеки машинного обучения.

🔹 2. BI-инструменты (Power BI, Yandex DataLens, Tableau)

Бизнес активно переходит на визуальную аналитику.
Особенно растёт популярность Yandex DataLens — за счёт локализации и интеграции с экосистемами Яндекса.

🔹 3. Бизнес-анализ и постановка задач

Аналитиков всё чаще нанимают на стыке бизнеса и IT.
Важно уметь понимать метрики, воронки продаж, ROI и продуктовые цели.

🔹 4. Визуализация и сторителлинг с данными

Работодатели ценят не только расчёты,
но и способность понятно показать результат — через графики, отчёты и презентации. Этот навык связывает технический анализ и управленческие решения.

🔹 5. Мягкие навыки (soft skills)

Критическое мышление, коммуникация, самообучение.
Современные аналитики работают в кросс-функциональных командах — умение отстаивать свои выводы и говорить на языке бизнеса становится не менее важным, чем владение SQL.

💬 Итог: чтобы быть востребованным аналитиком в 2025 году,
нужно сочетать инструменты, логику и умение объяснять данные людям.

⚙️ Функция COALESCE — простая подстановка значений в SQL

Когда в таблице встречаются NULL, логика запросов ломается.
Функция COALESCE помогает “подставить” значение по умолчанию, если значения отсутствуют, то есть вместо них NULL.

🔹 Как работает

SELECT COALESCE (NULL, 'default'); -- вернёт 'default'
SELECT COALESCE ('данные', 'default'); -- вернёт 'данные'

COALESCE просто берёт первое не-NULL значение из списка аргументов.

🔹 Пример:

SELECT name,
       COALESCE (phone, '— нет телефона —') AS phone_display
FROM clients;

Если в поле phone встретятся значения NULL, то вместо них выведется фраза: — нет телефона —.

🔹 Несколько значений:

SELECT COALESCE(email, backup_email, '— нет контактов —') AS contact
FROM users;

Здесь функция проверяет значения полей, заданных в скобках по порядку: email → backup_email → '— нет контактов —'.

🧠
COALESCE — это страховка от NULL,
и её можно использовать почти везде: в SELECT, ORDER BY, GROUP BY, даже в UPDATE.
Вообщем это очень крутая функция, знать о которой обязательно.

🧨 Почему SELECT * — это зло, и PostgreSQL тебе этого не простит ?

Когда ты пишешь SELECT *, где-то внутри PostgreSQL тихо плачет планировщик 😢 Потому что вместо одного красивого запроса ты запускаешь комбайн по растаскиванию кучи строк.

Вот почему:

1️⃣ Хеш-таблица при алгоритме соединения Hash Join пухнет до параметра work_mem (параметр, выделяющий память для обработки запросов).

Если ты делаешь JOIN, Postgres может выбрать алгоритм соединения Hash Join, как один из алгоритмов и хеш таблица будет построена по всем выбранным колонкам.
Когда ты ставишь *, туда летит всё подряд.
Результат — work_mem забит, планировщик начинает спиллинг на диск, и “быстрый” JOIN идёт пить кофе ☕️

2️⃣ TOAST говорит: “Приятного аппетита!”

Postgres хранит длинные значения (TEXT, JSONB и т.д.) в TOAST-таблицах. TOAST - это такая специальная технология для хранения больших значений в отдельных таблицах.
Если ты выбираешь *, он вытаскивает их в любом случае, даже если тебе нужно только id. То есть ты сам зовёшь на ужин все 10-гигабайтные тексты, которые никто не ел 🤦‍♂️

3️⃣ INDEX ONLY SCAN? Нет, не слышали.

INDEX ONLY SCAN - оптимизация при которой нужные в результате столбцы есть в самом индексе. То есть возможно не нужно обращаться к самой таблице, а достать все данные из самого индекса, работает очень быстро и эффективно.
Но SELECT * ломает эту оптимизацию — Postgres вынужден идти в heap (кучу строк), чтобы достать остальные поля.
И твой быстрый запрос превращается в медленный.

4️⃣ Лишние данные = лишняя нагрузка

Сеть, CPU, память — всё страдает.
Даже если приложение потом использует 2 поля из 20, Postgres всё равно тащит весь мешок данных и заботливо складывает тебе в ответ.

5️⃣ Буферный кеш засоряется

Postgres кеширует страницы данных в специальных буферах, для эффективного обмена нужными данными.
Когда ты выбираешь *, кеш наполняется ненужными колонками.
А потом, когда реально нужный запрос приходит — места уже нет 🤷‍♂️

💡 Вывод:

SELECT * — это как “всё включено” в отеле, где ты ешь один салат, но платишь за омаров, вино и шоу с фаерболами.
Пиши явно, что тебе нужно. PostgreSQL скажет “спасибо” и даст красивый план с INDEX ONLY SCAN.

Наверное многие слышали что * это плохо, но мало кто понимает почему. Это конечно не простая тема, если будут вопросы по пунктам пишите, буду пояснять.

📦 Что происходит, когда ты нажимаешь «Оформить заказ» (или меняешь данные в личном кабинете на сайте).

Ты жмёшь кнопку «Купить», и кажется — всё, магия! ✨
Но на самом деле под капотом запускается целая цепочка событий,
в которой участвуют браузер, сервер и база данных PostgreSQL.

Разберёмся пошагово 👇

🖱 1. Ты нажал кнопку на сайте

Браузер (например, Chrome) отправляет запрос серверу сайта.
Что-то вроде:

POST /order

Внутри — всё нужное: товар, количество, адрес доставки, твой логин.

Браузер не идёт напрямую в базу, он просто говорит серверу:

«Эй, вот заказ от пользователя №123!»

⚙️ 2. Сервер получает запрос и решает, что делать

На сервере работает программа (например, на Python, Node.js, PHP или Java).

Она:

- проверяет, что ты залогинен,
- что товар есть в наличии,
- считает сумму заказа,
- и готовит SQL-запрос к базе данных.

Примерно так:

INSERT INTO orders (user_id, product_id, quantity, address)
VALUES (123, 42, 2, 'ул. Примерная, д.7');

🧩 3. Сервер общается с PostgreSQL

Теперь приложение подключается к PostgreSQL (по внутреннему протоколу) и говорит:

«Postgres, вот SQL-запрос — запиши новый заказ!»

PostgreSQL принимает запрос, проверяет права и создаёт новую запись в таблице orders.

🧠 4. PostgreSQL обрабатывает запрос

Под капотом Postgres делает кучу работы:

находит таблицу orders,
выделяет место для новой строки,
записывает данные,
обновляет индексы,
и добавляет запись в журнал WAL (чтобы ничего не потерять при сбое).

Когда всё готово, он отвечает серверу:

«Всё, я сохранил заказ ✅»

📤 5. Сервер отправляет ответ браузеру

Сервер формирует ответ:

{"status": "ok", "message": "Заказ оформлен"}

и отправляет его обратно в браузер. А браузер показывает тебе красивую страницу:

«Спасибо за заказ!» 💙

💡 Итого:

Каждый раз, когда ты что-то делаешь на сайте —
оформляешь заказ, редактируешь профиль или ставишь лайк —
данные проходят длинный путь:
браузер → сервер → PostgreSQL → обратно к тебе на экран.

Никакой магии. Просто хорошо отлаженная система 💪

🧩 CASE WHEN — гибкая логика прямо в SQL.

CASE WHEN — это способ добавить в SQL немного “ума”.
Он позволяет выполнять условия прямо в запросах:
выбирать разные значения в зависимости от данных,
похож на конструкцию if...else в обычных языках программирования.

🧠 Когда используется CASE WHEN ?

- когда нужно преобразовать значения на лету;
- когда нужно разделить данные на категории;
- когда хотите добавить логику без подзапросов.

💡 Пример:

Допустим, у нас есть таблица пользователей users с количеством их публикаций — posts_count.
Нам нужно вывести, насколько активен каждый пользователь.

SELECT
      username,
      posts_count,
      CASE
        WHEN posts_count >= 20 THEN '🔥 Активный автор'
        WHEN posts_count BETWEEN 5 AND 19 THEN '🙂 Иногда пишет'
        ELSE '💤 Почти неактивен'
END AS activity_level
FROM users;

🔍 Разбор:

CASE WHEN проверяет условия сверху вниз.
Сначала смотрим, есть ли у пользователя 20 и больше постов.
Если да — возвращаем '🔥 Активный автор'.

Если нет — проверяем следующее условие: от 5 до 19 постов.
Подходит? Тогда '🙂 Иногда пишет'.

Если не сработало ни одно условие — выполняется ELSE, и возвращаем '💤 Почти неактивен'.

Результат появляется в новом столбце activity_level, который мы сами назвали в конце запроса.

🧩 Итого

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

- превращать цифры в осмысленные статусы,
- управлять порядком сортировки,
- или просто делать запросы “умнее”.

Не сравнивай свой прогресс с чужим.

Кто-то уже пишет сложные CTE и использует оконные функции, а ты всё ещё осваиваешь базовые JOIN — и это абсолютно нормально!

Учёба — не гонка. У каждого свой темп, свой стиль мышления и свой путь. Главное не просто повторять за другими, а реально понимать, как работают запросы и почему они нужны.

SQL — отличный инструмент для работы с данными, и его можно изучать шаг за шагом:

Сначала пройди основы: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY.

После того как простые запросы станут привычными, переходи к JOIN, учись объединять данные из разных таблиц.

Потом попробуй CTE (WITH) и оконные функции — они пригодятся для сложных задач.

Мотивационная инструкция:

Ставь реалистичные цели на неделю или месяц (например, освоить один тип JOIN или научиться писать простой SELECT с GROUP BY)

Практикуйся регулярно — даже 20 минут в день

Не стесняйся ошибаться, пробуй разные подходы

Старайся учиться на задачах, которые тебе интересны и полезны

Окружай себя поддержкой: общайся с единомышленниками, участвуй в сообществе и делись успехами

Если кажется, что идёшь медленно — это иллюзия! Ты уже знаешь гораздо больше, чем вчера, и движешься к своей цели.

💣 Атомарность транзакций — “всё или ничего” в действии.

Прежде чем разбираться, давай коротко — что такое транзакции.

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

Например, перевод денег, оформление заказа или обновление профиля — всё это делается через транзакции.

Чтобы база оставалась надёжной, транзакции подчиняются четырём свойствам — ACID:

A — Atomicity (атомарность) — всё или ничего
C — Consistency (согласованность)
I — Isolation (изолированность)
D — Durability (надёжность, сохранность)

Сегодня разберём первую букву — атомарность 👇

⚙️ Что значит “атомарно”

Атомарность (Atomicity) — это гарантия, что транзакция выполнится полностью или не выполнится вовсе. Если где-то посередине произошёл сбой (например, свет моргнул, сеть отвалилась, диск не ответил) — PostgreSQL откатит всё, как будто ничего не происходило.

💰 Пример с переводом денег:

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1; — списываем деньги с одного счета

UPDATE accounts SET balance = balance + 100 WHERE id = 2; — зачисляем на другой счет

COMMIT;

💡 Если всё прошло успешно — COMMIT зафиксирует изменения в базе.
💥 Если один из шагов упадёт (например, второй UPDATE не выполнится) — PostgreSQL автоматически откатит транзакцию:

сделает ROLLBACK;

И оба счёта останутся без изменений.
То есть либо оба действия проходят, либо ни одно.

🧠 Почему это важно

Без атомарности могли бы быть такие “чудеса”:

со счёта A деньги списались,

на счёт B — не пришли.

И всё, нормальное состояние базы данных нарушено.

Атомарность спасает от этого, гарантируя, что база данных никогда не окажется “наполовину обновлённой”.

⚡️

Итого

Атомарность — это “всё или ничего”.

PostgreSQL делает так, чтобы любая операция внутри транзакции была неделимой и безопасной.

Разбор загадки: логические OR и AND.

На первый взгляд кажется, что правильный вариант —

SELECT * FROM products WHERE category = 'Books' OR category = 'Electronics' AND price > 1000;

но... это не так 😏

⚙️ Что происходит на самом деле

SQL, как и большинство языков, имеет приоритет операторов.
AND выполняется раньше, чем OR.

Поэтому запрос читается вот так:

WHERE category = 'Books' OR (category = 'Electronics' AND price > 1000)

А значит — в результат попадут:

все товары из категории Books (независимо от цены),
и только те товары из Electronics, где price > 1000.
💥 То есть дешёвые книги тоже окажутся в выборке, которые стоят меньше 1000.

✅ Правильный вариант

Чтобы выбрать товары только дороже 1000 и из двух категорий, нужно "изолировать" условия скобками:

SELECT * FROM products 
WHERE (category = 'Books' OR category = 'Electronics') AND price > 1000;

Теперь порядок вычисления ясен:
1️⃣ выбираются категории Books или Electronics,
2️⃣ применяется фильтр по цене, но именно к одной из категорий в скобках.

🧠 Почему это важно

Такие мелочи часто ломают бизнес-логику:

в отчёте появляются лишние строки,

фильтры работают “почти правильно”,

разработчик уверен, что всё ок — пока аналитик не замечает странные данные.

SQL не “угадывает” твои намерения — он строго следует приоритетам операторов.

💡 Вывод

AND сильнее OR.
Если хочешь, чтобы условия работали как тебе нужно —
ставь скобки и не надейся на интуицию.

⚙️ Основные операторы в SQL-запросе.

SQL-запрос — это как предложение на человеческом языке:
у него есть структура, логика и свой порядок выполнения.
Разберём каждую часть на простых примерах 👇

🧩 Общий синтаксис SQL-запроса

SELECT <столбцы или выражения>
FROM <таблица, подзапрос, функция>
WHERE <условие фильтрации>
GROUP BY <группировка>
HAVING <условие фильтрации для групп>
ORDER BY <сортировка>
LIMIT <ограничение количества строк>;

💡 Важно: порядок написания != порядок выполнения.
SQL выполняет команды вот так, в отличии от синтаксического написания:

👉 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

🔹 SELECT — что выбираем

Используется, чтобы выбрать нужные данные.

Можно:
выбрать все столбцы с помощью *,

выбрать только нужные:

SELECT name, price FROM products;

задавать псевдонимы полям для удобства:

SELECT price AS cost, name AS product_name FROM products;

💡 Псевдонимы (AS) можно использовать в ORDER BY, но не в WHERE, GROUP BY (PostgreSQL можно) или HAVING.

🔹 FROM — откуда выбираем

Указывает источник данных: таблицу, подзапрос, JOIN или даже функцию.

FROM users
JOIN orders ON users.id = orders.user_id;


Можно подставлять функции, например:

FROM generate_series(1,10);

🔹 WHERE — фильтр строк

Фильтрует строки до группировки.

WHERE price > 1000 AND category = 'Electronics';


💡 Работают логические операторы AND, OR, NOT, а также IN, LIKE, BETWEEN.
❗️ Псевдонимы из SELECT здесь использовать нельзя.

🔹 GROUP BY — группировка

Объединяет строки по признаку для агрегирования (например для подсчета суммы SUM, или количества COUNT для групп).

GROUP BY category;


💡 Здесь нельзя использовать псевдонимы из SELECT (в PostgreSQL можно),
но можно использовать выражения и номера столбцов:

GROUP BY 1; -- по первому столбцу из SELECT

🔹 HAVING — фильтр после группировки

Применяется уже к агрегированным данным:

HAVING COUNT(*) > 10;


💡 Псевдонимы из SELECT также недоступны — только реальные имена или агрегаты.

🔹 ORDER BY — сортировка

Сортирует строки по нужному полю.

ORDER BY price ASC; 
ORDER BY price DESC;

ASC — по возрастанию (по умолчанию можно не писать)

DESC — по убыванию
💡 Здесь можно использовать псевдонимы из SELECT и номера столбцов:

ORDER BY 2 DESC;

🔹 LIMIT / OFFSET — ограничение выборки

Ограничивает количество возвращаемых строк:

LIMIT 10 - выводит 10 строк
OFFSET 20 - отступает первые 20 строк


💡 Псевдонимы здесь не применяются, так как это уже финальная стадия результата.

🔢 Разница между COUNT(*), COUNT(id) и COUNT(DISTINCT id)

В SQL эти три конструкции вроде бы похожи, но на деле ведут себя по-разному.
Разберём их на понятном примере с таблицей orders, которая изображена на картинке.

1️⃣ COUNT(*):

SELECT COUNT(*) FROM orders;

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

2️⃣ COUNT(user_id):

SELECT COUNT(user_id) FROM orders;

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

3️⃣ COUNT(DISTINCT user_id):

SELECT COUNT(DISTINCT user_id FROM orders;

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

📘 Итого:

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

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

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

👨‍💻 Кто есть кто в мире данных (2025): короткий и понятный разбор

Мир данных развивается быстро — и роли внутри него тоже.
Вот актуальный гайд по ключевым направлениям в 2025 году: чем занимаются специалисты и где они востребованы.

📊 Data Analyst

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

Что делает:

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

🧱 Data Engineer

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

Что делает:

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

🛡 DBA (Database Administrator)

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

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

Что делает:

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

🤖 Data Scientist

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

Что делает:

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

📌 Итог: роли не конкурируют — они дополняют друг друга

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

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

🔍 Где использовать условия в операциях JOIN в SQL?

Выполняя соединение таблиц, особенно это касается LEFT JOIN очень важно понимать куда вставить условие фильтрации.

✅ Пример 1: INNER JOIN + WHERE

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.

⚠️ Пример 2: LEFT JOIN + WHERE

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.

⭐️ Пример 3: LEFT JOIN + фильтр в ON

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 — это так просто.

Да и постоянно слышишь: «Да чему там учиться, за две недели освоишь!»
И поначалу действительно так и кажется — пишешь себе спокойный и простой SELECT, чувствуешь себя уверенно, жизнь прекрасна.

Но потом приходит ОН.
Подзапрос.
А за ним — подзапрос в подзапросе.
А внутри — ещё один подзапрос, который смотрит на тебя так, будто проверяет, действительно ли ты хочешь заниматься аналитикой 😄

И вот ты уже сидишь, смотря на конструкцию длиной в километр, и думаешь:
«Может, это какой-то тест? Может, это вообще не SQL?»

SQL интуитивен и логичен…
Пока не наступит момент, когда интуиция сдаётся и отследить логику становится крайне сложно.

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