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

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

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

Как 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 остаётся ключевым языком для работы с данными благодаря своей зрелости, универсальности и устойчивости. Он доказал свою эффективность временем, а современная индустрия только укрепляет его позиции.