Оптимистическая блокировка: обновляем данные без конфликтов!

Когда несколько пользователей редактируют одну запись, можно избежать конфликтов с помощью оптимистической блокировки — без явного FOR UPDATE.

Создаём таблицу с версией записи:

CREATE TABLE products (
    id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT,
    price DECIMAL(10,2),
    version INT DEFAULT 1 NOT NULL
);

Выбираем запись для редактирования:

SELECT id, name, price, version
FROM products
WHERE id = 1;

Обновляем с проверкой версии:

UPDATE products
SET price = 199.99,
    version = version + 1
WHERE id = 1
  AND version = 1;

Если другой пользователь уже изменил эту строку, UPDATE не затронет ни одной записи — значит, версия изменилась, и данные устарели.

Приложение должно проверить, что rows_affected = 1, и при необходимости повторить попытку или показать сообщение об ошибке.

Проверяем результат:

SELECT * FROM products WHERE id = 1;

🔥 Такой подход предотвращает «потерю обновлений» без длительных блокировок чтения и подходит для большинства современных СУБД.

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

Нужно найти, где бронирования, подписки или сессии пересекаются по времени?

Два интервала пересекаются, если начало одного раньше конца другого, и наоборот:

a.start_at < b.end_at
AND b.start_at < a.end_at

Это условие покрывает все случаи перекрытий, даже частичных и вложенных.

Теперь объедини данные сами с собой:

SELECT a.id, b.id
FROM bookings a
JOIN bookings b
  ON a.id < b.id
 AND a.start_at < b.end_at
 AND b.start_at < a.end_at;

a.id < b.id, чтобы не получить пары в обе стороны.

Хочешь анализировать бронирования по ресурсу? Добавь фильтр:

AND a.room_id = b.room_id

🔥 Теперь видно, какие заявки реально конфликтуют по времени.

➡️ SQL Ready | #совет

Сгенерированные колонки в PostgreSQL: ускоряем фильтры без лишних вычислений!

Когда одно и то же выражение постоянно считается в WHERE, запросы тормозят. В PostgreSQL это решается GENERATED ALWAYS AS … STORED — выражение вычисляется один раз и хранится как обычное поле.

Создаём таблицу с материализованным выражением:

CREATE TABLE events (
    id BIGSERIAL PRIMARY KEY,
    payload JSONB NOT NULL,
    event_type TEXT GENERATED ALWAYS AS (payload->>'type') STORED
);

Теперь event_type больше не вычисляется на лету — значение лежит прямо в строке.

Фильтрация становится проще и быстрее:

SELECT id
FROM events
WHERE event_type = 'purchase';

Добавляем индекс:

CREATE INDEX idx_events_event_type
    ON events(event_type);

Проверяем:

EXPLAIN ANALYZE
SELECT id
FROM events
WHERE event_type = 'purchase';

🔥 Должен быть Index Scan, без тяжёлых операций над JSONB. Сгенерированные колонки отлично подходят для повторяющихся вычислений:

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