Шпаргалка по оконным функциям и агрегатам для нумерации строк, поиска и анализа дубликатов, ранжирования результатов и аккуратного удаления лишних записей. Используется при очистке данных, аналитических запросах, построении рейтингов и подготовке данных к миграциям и отчётности.Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥8🤝7
Как получить «последнюю запись на группу»?
Очень частая задача - взять последнюю запись на пользователя, заказ, сущность. Многие делают это с
Так первой будет именно самая свежая запись.
Если возможны одинаковые
Если нужно выбрать конкретные поля и избежать
Выражения из
🔥 Такой запрос часто читается проще, чем
➡️ 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) может давать отличный план выполнения.Please open Telegram to view this post
VIEW IN TELEGRAM
👍20❤7🔥6🤝3
В системах бронирования одна из частых ошибок - это пересечение интервалов, когда один и тот же ресурс оказывается занят сразу несколькими пользователями.
Сегодня в задаче:
• Сравним бронирования одного ресурса между собой, не создавая дубликатов;
• Проверим пересечение временных интервалов с помощью канонического условия;
• Получим список конфликтующих бронирований, которые система должна блокировать.
Это базовый инструмент контроля данных в системах бронирования, календарях, слотах доставки и любых сервисах с ограниченными ресурсами.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥13❤5🤝4
This media is not supported in your browser
VIEW IN TELEGRAM
Этот сайт помогает анализировать структуры данных: деревья, графы, обходы и множество другого. Здесь нет решений задач или подготовкой к собеседованиям, упор именно на понимание того, как и почему всё устроено. Материал подается последовательно и концептуально, поэтому хорошо подходит даже новичкам.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👍9🤝7🔥2
LEFT JOIN и WHERE — классическая ловушка с NULL!
Таблицы:
Нужно получить всех пользователей и их заказы (если есть):
Если у пользователя нет заказов, поля из
Теперь типичная ошибка:
Условие в
В результате пользователи без заказов исчезают, и запрос фактически работает как
Правильный вариант — переносить условия на правую таблицу в
Теперь: пользователи без заказов остаются в результате, фильтрация применяется только к связанным строкам
Если же логика действительно требует убрать пользователей без заказов, тогда честнее писать
Так намерение запроса читается однозначно.
🔥 Условия в
➡️ SQL Ready | #практика
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 влияют только на логику связывания таблиц.Please open Telegram to view this post
VIEW IN TELEGRAM
👍24❤14🔥8🤝2
This media is not supported in your browser
VIEW IN TELEGRAM
Репозиторий с понятным и структурированным разбором баз данных на русском языке. Здесь разобраны ключевые концепции SQL для MySQL и PostgreSQL, есть примеры запросов и задачи для самостоятельной работы. Отлично подходит для укрепления базы и подготовки к собеседованиям.
Оставляю ссылочку: GitHub📱
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍8🤝5❤3
При прямом UPDATE данные теряют историю: невозможно корректно восстановить состояние сущности на дату или отследить момент изменения.
Сегодня в гайде:
• Как моделировать версионные данные через valid_from / valid_to;
• Как корректно закрывать предыдущую версию и создавать новую;
• Как получать актуальное состояние и исторические срезы без дополнительной логики.
SCD Type 2 хранит каждое изменение как отдельную версию строки с фиксированным интервалом актуальности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍10🤝8🔥3