LEFT JOIN и WHERE — классическая ловушка с NULL!

LEFT JOIN используют, когда нужно сохранить строки из левой таблицы, даже если в правой нет совпадений. Но одно неверное условие в WHERE — и LEFT JOIN незаметно превращается в INNER JOIN.

Таблицы:

users(id, email)
orders(id, user_id, amount)

Нужно получить всех пользователей и их заказы (если есть):

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

Если у пользователя нет заказов, поля из orders будут NULL — это ожидаемое поведение LEFT JOIN.

Теперь типичная ошибка:

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

Условие в WHERE отфильтровывает строки, где o.amount IS NULL.
В результате пользователи без заказов исчезают, и запрос фактически работает как INNER JOIN.

Правильный вариант — переносить условия на правую таблицу в ON:

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

Теперь: пользователи без заказов остаются в результате, фильтрация применяется только к связанным строкам orders.

Если же логика действительно требует убрать пользователей без заказов, тогда честнее писать INNER JOIN:

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

Так намерение запроса читается однозначно.

🔥 Условия в WHERE применяются после JOIN и могут уничтожить строки с NULL. Условия в ON влияют только на логику связывания таблиц.

➡️ SQL Ready | #практика

😎 Сodedokode/pasta — теория + задачи на практике!

Репозиторий с понятным и структурированным разбором баз данных на русском языке. Здесь разобраны ключевые концепции SQL для MySQL и PostgreSQL, есть примеры запросов и задачи для самостоятельной работы. Отлично подходит для укрепления базы и подготовки к собеседованиям.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

📂 Напоминалка для работы с алгоритмами выбора лидера в распределённых системах!

Например, Raft выбирает лидера через голосование, Paxos использует кворум, а Bully Algorithm назначает лидером узел с максимальным ID.

На картинке — 5 базовых алгоритмов leader election, которые используются в распределённых БД и системах координации.

Сохрани, чтобы не забыть!

➡️ SQL Ready | #ресурс

NULL и сравнения — почему = и <> с NULL не работают!

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

Таблица:

users(id, email, deleted_at)

Нужно выбрать неудалённых пользователей.

Типичный, но неправильный запрос:

SELECT *
FROM users
WHERE deleted_at = NULL;

Запрос выполнится, но вернёт 0 строк.

Почему так — SQL выражение:

deleted_at = NULL

никогда не бывает TRUE.

Любое сравнение с NULL (=, <>, <, >) возвращает UNKNOWN, а WHERE пропускает только TRUE.

То же самое с отрицанием:

WHERE deleted_at <> NULL;

Результат — тоже пусто.

Правильный способ — IS NULL:

SELECT *
FROM users
WHERE deleted_at IS NULL;

И обратное условие:

SELECT *
FROM users
WHERE deleted_at IS NOT NULL;

IS NULL и IS NOT NULL — всегда возвращают TRUE или FALSE, никогда UNKNOWN.

Частая скрытая ошибка в составных условиях:

WHERE status = 'active'
  AND deleted_at <> '2026-01-01'

Если deleted_at равен NULL, всё выражение становится UNKNOWN, и строка отбрасывается, даже если status = 'active'.

Корректная проверка «не удалён»:

WHERE status = 'active'
  AND deleted_at IS NULL

Важно помнить про OR:

WHERE role = 'admin'
   OR deleted_at IS NULL

Здесь логика работает ожидаемо, потому что IS NULL не возвращает UNKNOWN, а значит выражение может стать TRUE.

🔥 Практические правила: = и <> с NULL не работают в WHERE; любой UNKNOWN в WHERE — строка отбрасывается. Если строка пропала из результата — первым делом проверяй условия с NULL

➡️ SQL Ready | #практика

Знали, что в SQL можно получить несколько уровней агрегации за один проход по данным?

Частая задача - посчитать метрики сразу на нескольких уровнях: по стране и статусу, только по стране и общий итог. Обычно для этого пишут несколько SELECT и склеивают их UNION ALL:

SELECT country, status, COUNT(*) FROM orders GROUP BY country, status
UNION ALL
SELECT country, NULL, COUNT(*) FROM orders GROUP BY country
UNION ALL
SELECT NULL, NULL, COUNT(*) FROM orders;

GROUPING SETS позволяет описать все нужные уровни агрегации в одном GROUP BY:

GROUP BY GROUPING SETS ((country, status), (country), ())

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

Строка с пустыми скобками () - это глобальный итог. Колонки, которые не участвуют в текущем уровне, приходят как NULL:

(country = NULL, status = NULL)

🔥 Этот приём особенно полезен в отчётах и аналитике, где нужны totals, subtotals и детализация одновременно.

➡️ SQL Ready | #совет

NULL и сравнения — почему = и <> с NULL не работают!

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

Таблица:

users(id, email, deleted_at)

Нужно выбрать неудалённых пользователей.

Типичный, но неправильный запрос:

SELECT *
FROM users
WHERE deleted_at = NULL;

Запрос выполнится, но вернёт 0 строк.

Почему так — SQL выражение:

deleted_at = NULL

никогда не бывает TRUE.

Любое сравнение с NULL (=, <>, <, >) возвращает UNKNOWN, а WHERE пропускает только TRUE.

То же самое с отрицанием:

WHERE deleted_at <> NULL;

Результат — тоже пусто.

Правильный способ — IS NULL:

SELECT *
FROM users
WHERE deleted_at IS NULL;

И обратное условие:

SELECT *
FROM users
WHERE deleted_at IS NOT NULL;

IS NULL и IS NOT NULL — всегда возвращают TRUE или FALSE, никогда UNKNOWN.

Частая скрытая ошибка в составных условиях:

WHERE status = 'active'
  AND deleted_at <> '2026-01-01'

Если deleted_at равен NULL, всё выражение становится UNKNOWN, и строка отбрасывается, даже если status = 'active'.

Корректная проверка «не удалён»:

WHERE status = 'active'
  AND deleted_at IS NULL

Важно помнить про OR:

WHERE role = 'admin'
   OR deleted_at IS NULL

Здесь логика работает ожидаемо, потому что IS NULL не возвращает UNKNOWN, а значит выражение может стать TRUE.

🔥 Практические правила: = и <> с NULL не работают в WHERE; любой UNKNOWN в WHERE — строка отбрасывается. Если строка пропала из результата — первым делом проверяй условия с NULL

➡️ SQL Ready | #практика

📂 Напоминалка по типам баз данных!

Например, Relational / SQL базы подходят для строгих транзакций и сложных связей, Time-series — для метрик, логов и мониторинга, а NoSQL — когда важны масштабирование, гибкость схемы и высокая нагрузка.

На картинке — 3 типа баз данных с примерами и их основными особенностями.

Сохрани, чтобы не забыть!

➡️ SQL Ready | #ресурс

✍️ QOMP — квиз для проверки знаний и закрепления навыков!

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

📌 Оставляю ссылочку: qomp.club

➡️ SQL Ready | #ресурс