💡 На Хабре вышла мега годная статья: «Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99%»!

В этой статье:
• О системе обработки огромного потока форм — от поиска до подачи объявлений;
• Подробно объясняется, зачем команде нужен уровень надёжности SLI 99.99%;
• Описаны оригинальные подходы к версионированию данных, изоляции изменений;
• Приводятся реальные схемы работы с SQL/NoSQL, кэшами и стратегиями graceful degradation при отказах.

🔊 Продолжайте читать на Habr!

➡️ SQL Ready | #статья

Как получить «последнюю запись на группу»?

Очень частая задача - взять последнюю запись на пользователя, заказ, сущность. Многие делают это с ROW_NUMBER(), хотя Postgres умеет проще:

SELECT DISTINCT ON (user_id) *
FROM orders
ORDER BY user_id, created_at DESC;

DISTINCT ON оставляет первую строку в рамках группы, а порядок задаётся через ORDER BY:

ORDER BY user_id, created_at DESC

Так первой будет именно самая свежая запись.

Если возможны одинаковые created_at, лучше явно добавить тай-брейкер:

ORDER BY user_id, created_at DESC, id DESC

Если нужно выбрать конкретные поля и избежать SELECT *, просто укажите нужные колонки:

SELECT DISTINCT ON (user_id)
       user_id, id, created_at
FROM orders
ORDER BY user_id, created_at DESC, id DESC;

Выражения из DISTINCT ON (...) обязаны быть левым префиксом ORDER BY, иначе Postgres выдаст ошибку.

🔥 Такой запрос часто читается проще, чем ROW_NUMBER(), и при подходящем индексе (user_id, created_at DESC, id DESC) может давать отличный план выполнения.

➡️ SQL Ready | #совет

❤️ AlgoTree — понятные объяснения алгоритмов, деревьев и графов!

Этот сайт помогает анализировать структуры данных: деревья, графы, обходы и множество другого. Здесь нет решений задач или подготовкой к собеседованиям, упор именно на понимание того, как и почему всё устроено. Материал подается последовательно и концептуально, поэтому хорошо подходит даже новичкам.

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

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

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 | #репозиторий