SQL-ловушка: этот UPDATE может незаметно испортить данные в продакшене

Код корректный, PostgreSQL не выдаст ошибку. Но результат не так очевиден.

Есть таблица товаров:

CREATE TABLE products (
    id INT PRIMARY KEY,
    price INT
);

INSERT INTO products VALUES (1, 100);

Применяем скидки:

WITH discounts(id, amount) AS (
    VALUES (1, 10), (1, 20)
)
UPDATE products p
SET price = p.price - d.amount
FROM discounts d
WHERE p.id = d.id;

SELECT price FROM products;

Что вернёт последний SELECT?

А) 90
Б) 80
В) 70
Г) 80 или 90, результат не гарантирован

Один запрос, две скидки на один товар. Как PostgreSQL обработает такой UPDATE?

Подвох связан с поведением UPDATE ... FROM, о котором легко забыть даже при работе с реальными базами.

ORM превратила один SQL-запрос в 51. Разработчик даже не заметил

Знакомая ситуация: код выглядит чисто, никаких SQL-запросов вручную, всё через ORM.

Например, в Django:

posts = Post.objects.all()[:50]

for post in posts:
    print(post.author.name)

Кажется, что мы просто получаем 50 постов с авторами. Но на практике это может вызвать 51 запрос к базе данных.

Один запрос загружает посты, а ещё 50 отдельно получают авторов.

Это классическая проблема N+1 queries. Причём чем больше записей, тем больше обращений к БД.

Исправляется одной строкой:

posts = Post.objects.select_related("author")[:50]

Теперь Django использует JOIN и получает посты вместе с авторами одним запросом.

ORM избавляет от написания SQL, но не от необходимости понимать, какой SQL выполняется.

Именно поэтому при оптимизации API полезнее сначала посмотреть на количество запросов, чем переписывать Python-код ради нескольких миллисекунд.

SQL-задача с подвохом: найдите пользователей, которые вернулись после 30 дней молчания

Представьте, что вы анализируете активность пользователей сервиса. Нужно найти тех, кто вернулся после длительного перерыва.

Есть таблица PostgreSQL:

CREATE TABLE events (
    user_id INT,
    event_time TIMESTAMP
);

INSERT INTO events VALUES
(1, '2026-10-01 10:00'),
(1, '2026-10-01 12:00'),
(1, '2026-11-01 09:00'),
(1, '2026-11-02 14:00'),
(2, '2026-10-01 10:00'),
(2, '2026-10-31 10:00'),
(3, '2026-09-01 10:00'),
(3, '2026-11-05 10:00'),
(3, '2026-11-05 11:00');

Задача: для каждого пользователя найти все даты возвращения после 30 полных календарных дней без активности.

Ожидаемый результат:

| user_id | return_date |
|---|---|
| 1 | 2026-11-01 |
| 3 | 2026-11-05 |

Условия: несколько событий в один день считаются одной активностью. День последней активности и день возвращения в период молчания не входят. Например, между 1 октября и 31 октября только 29 полных дней без активности, а между 1 октября и 1 ноября уже 30.

Ограничение: решите задачу одним SQL-запросом, без процедур, временных таблиц и циклов.

На первый взгляд достаточно LAG(), но если не учесть дубли событий и границы календарных дней, результат окажется неправильным.

Как бы вы решили эту задачу на PostgreSQL?