🧩 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 интуитивен и логичен…
Пока не наступит момент, когда интуиция сдаётся и отследить логику становится крайне сложно.

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

А вот сам запрос.

Как SQL до сих пор держит позиции — и почему это хорошо.

SQL остаётся одним из самых востребованных и долгоживущих языков в сфере работы с данными. Несмотря на постоянное появление новых подходов, форматов и СУБД, он продолжает занимать устойчивое место практически во всех областях, связанных с хранением и анализом информации.

1. SQL — зрелый и стандартизированный инструмент

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

2. Широкое распространение реляционных баз данных

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

3. Повышенные требования к структуре и надёжности

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

4. SQL хорошо подходит для аналитических задач

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

5. SQL эволюционирует вместе с индустрией

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

Итог.

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

Среднее значение часто звучит «научно» и убедительно, но в реальности легко маскирует проблему и красиво приукрашивает картину.

Почему «средняя» цифра может обмануть ?

Пример 1. Классика жанра: зарплаты.

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

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

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

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

Пример 2. Средний чек.

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

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

Но если:

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

Пример 3. Время отклика сервера.

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

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

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

🎯 Так что же использовать?

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

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

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

Сегодня посетил конференцию, которая называется Форум ДПО 2025 "Человек и компетенции нового времени".

Проходила она в Культурный центр НИУ ВШЭ. В книжном магазине универа приобрел интересную книгу "Парадокс искусственного интеллекта".

Успел прочитать одну первую статью. Много споров и обсуждений сейчас вокруг ИИ. Максимально сжал статью, чтобы коротко донести одно из мнений авторов книги.

"Современные технологии делают нашу жизнь удобнее и быстрее, но риск – мы всё чаще доверяем сложные размышления и принятие решений не себе, а машинам и сервисам. Постепенно появляется зависимость не только от гаджетов, но и от тех, кто «думает за нас»: поисковые системы, нейросети, даже алгоритмы соцсетей.

Главная опасность не в эрозии знаний или грамотности, а в постепенной потере навыка думать самостоятельно. Когда привычка делегировать размышления забирает инициативу, люди теряют творческую уверенность, критическое восприятие и способность анализировать даже простые задачи. Это влияет на образование – выпускники с отличными сертификатами не всегда могут решить реальные задачи, если привыкли к готовым ответам.

Не так страшна безграмотность, как деградация мышления: если перестать размышлять, даже самые современные технологии будут лишь инструментом, а не опорой для развития. Поэтому важно не только обучаться, но и учиться мыслить – развивать самостоятельность, любознательность, способность искать нестандартные решения.

В итоге: пусть машинные помощники облегчают быт, но своё мышление отдавать на аутсорсинг нельзя! Будущее принадлежит тем, кто умеет принимать решения сам, творить, пробовать новое — а не просто следовать за алгоритмами."

Вот такое интересное и вероятно обоснованное мнение. Тема очень острая конечно сейчас.