Хочешь узнать, когда именно заказ сменил статус?

Используй LAG(), она возвращает значение из предыдущей строки в рамках группы:

LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at)

Сравни текущее значение с предыдущим:

status <> LAG(status) OVER (...)

Получается булево поле — true, когда статус поменялся.

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

SELECT *
FROM (
  SELECT order_id, status, updated_at,
         status <> LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at) AS changed
  FROM order_status_log
) t
WHERE changed;

🔥 Это основа для аудита изменений и аналитики событийных логов.

➡️ SQL Ready | #совет

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

Когда несколько пользователей редактируют одну запись, можно избежать конфликтов с помощью оптимистической блокировки — без явного 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 | #практика