🐱 SQL Window Functions — информативный гайд по оконным функциям в SQL!

Отличный ресурс для тех, кто хочет разобраться в SQL и освоить оконные функции. На сайте подробно объясняются инструменты для аналитики и сложной обработки данных. Всё сопровождается наглядными примерами и практическими кейсами.

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

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

Транзакционная блокировка без блокировки строк!

Иногда нужно запретить параллельную обработку одного объекта, но подходящей строки для FOR UPDATE ещё может не быть.

SELECT pg_advisory_xact_lock(10, 42);

pg_advisory_xact_lock создаёт транзакционную пользовательскую блокировку. Первый аргумент удобно использовать как namespace, второй — как id объекта.

SELECT pg_advisory_xact_lock(20, user_id);

Пока транзакция не завершится, другой процесс с тем же ключом будет ждать. После COMMIT или ROLLBACK блокировка снимается автоматически.

SELECT pg_try_advisory_xact_lock(20, user_id);

Если ждать нельзя, используй pg_try_advisory_xact_lock: он сразу вернёт true или false, и приложение сможет аккуратно пропустить задачу.

BEGIN;
SELECT pg_advisory_xact_lock(30, 123);
UPDATE invoices SET status = 'paid' WHERE id = 123;
COMMIT;

advisory lock не блокирует таблицу и не заменяет ограничения БД. Это кооперативная блокировка, поэтому все участники должны использовать один и тот же ключ.

🔥 Полезно для идемпотентных операций, генерации документов, биллинга, обработки вебхуков и любых мест, где один и тот же объект нельзя обрабатывать параллельно.

➡️ SQL Ready | #совет

👍 PostgreSQL Performance Essentials — практическое руководство по оптимизации PostgreSQL!

Этот репозиторий особенно полезен тем, кто уже работает с PostgreSQL и хочет больше разобраться в производительности базы данных. Здесь хорошо показано, как анализировать запросы, понимать execution plan и находить узкие места, которые замедляют работу приложения.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Lost Update: почему транзакций недостаточно без правильной модели конкурентного доступа!

Очень распространённое заблуждение: если запросы выполняются внутри транзакции — значит данные уже защищены от гонок, но это не так.

Одна из классических проблем конкурентного доступа — lost update. Например, есть таблица:

accounts(id, balance)

Текущий баланс:

id | balance
1  | 1000

Два запроса одновременно читают баланс:

SELECT balance
FROM accounts
WHERE id = 1;

Оба получают: 1000. Дальше: первый процесс хочет списать 100; второй — 200. Первый считает: 1000 - 100 = 900. Второй: 1000 - 200 = 800.

После этого выполняются:

UPDATE accounts
SET balance = 900
WHERE id = 1;

а также:

UPDATE accounts
SET balance = 800
WHERE id = 1;

В итоге финальный баланс: 800, хотя математически должен быть: 700, одно обновление потерялось. Это и есть lost update.

И самое неприятное — такое может происходить даже внутри транзакций. Всё зависит от уровня изоляции, паттерна обновления и механики блокировок конкретной СУБД.

Очень частая ошибка выглядит так:

BEGIN;

SELECT balance
FROM accounts
WHERE id = 1;

-- вычисления в приложении

UPDATE accounts
SET balance = :new_balance
WHERE id = 1;

COMMIT;

Проблема в том, что между SELECT и UPDATE другая транзакция может изменить строку.

Один из самых надёжных вариантов — атомарное обновление:

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

Теперь вычисление происходит внутри самого UPDATE.

СУБД выполняет обновление на основе актуального значения строки и использует необходимые механизмы блокировок для корректной синхронизации конкурентных изменений. Это намного безопаснее.

Ещё один вариант — pessimistic locking:

SELECT balance
FROM accounts
WHERE id = 1
FOR UPDATE;

FOR UPDATE ставит row-level lock. Пока транзакция не завершится, другая транзакция не сможет изменить эту строку или получить несовместимую блокировку на неё.

Но здесь есть trade-off, чем больше блокировок: тем выше contention; тем ниже concurrency; тем выше риск deadlock.

Ещё один подход — optimistic locking. Например:

accounts(id, balance, version)

Чтение:

SELECT balance, version
FROM accounts
WHERE id = 1;

Обновление:

UPDATE accounts
SET
  balance = :new_balance,
  version = version + 1
WHERE
  id = 1
  AND version = 5;

Если другая транзакция уже изменила строку — UPDATE затронет 0 строк. Приложение понимает: данные устарели, нужно перечитать и повторить операцию. Ещё важно понимать: READ COMMITTED, REPEATABLE READ, SERIALIZABLE ведут себя по-разному в разных СУБД.

Например, PostgreSQL и MySQL (InnoDB) используют разные механизмы MVCC и имеют различия в поведении блокировок и уровней изоляции.

🔥 Главное правило, если логика выглядит как: прочитал значение — изменил в приложении — записал обратно, то всегда стоит проверять, не появляется ли lost update при параллельных запросах.

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

👍 ClickHouse + PostgreSQL — интеграция OLTP и OLAP для аналитики!

На странице собрана официальная документация ClickHouse по работе с PostgreSQL. Здесь подробно разбираются импорт данных, репликация таблиц, синхронизация и выполнение запросов к PostgreSQL напрямую из ClickHouse. Также есть примеры настройки и практические сценарии использования.

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

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

⚡️ Айтишник из «VISION» скупил курсы айти школ и выложил гигабайты материалов к себе

Каждый найдет что-то по душе:

1202 ГБ — Python
1811 ГБ — Frontend
1100 ГБ — C / C++ / C#
804 ГБ — Java
411 ГБ — SQL & БД
309 ГБ — DevOps
998 ГБ — ИБ & Хакинг
773 ГБ — Kotlin / Swift
189 ГБ — PHP
201 ГБ — GoLang
170 ГБ — Rust
167 ГБ — QA / Тестирование
310 ГБ — 1C + Лицензии
495 ГБ — Машинное обучение
704 ГБ — Аналитика Данных
991 ГБ — Дизайн

Материалы в закрепе, постоянно пополняются👆🏻

Разбор JSON в строки на стороне PostgreSQL!

Когда из API прилетает массив объектов, не обязательно разбирать его в коде и делать много отдельных INSERT или UPDATE. PostgreSQL умеет превратить JSON-массив в обычную табличную выборку.

SELECT *
FROM jsonb_to_recordset($1::jsonb)
AS x(id bigint, amount numeric);

На вход можно передать JSON вида [{"id":1,"amount":500},{"id":2,"amount":900}], а на выходе получить нормальные типизированные строки.

INSERT INTO payments (id, amount)
SELECT id, amount
FROM jsonb_to_recordset($1::jsonb)
AS x(id bigint, amount numeric);

Это особенно удобно для пакетных загрузок, импорта данных, обработки вебхуков и синхронизации с внешними сервисами.

UPDATE payments p
SET amount = x.amount
FROM jsonb_to_recordset($1::jsonb)
AS x(id bigint, amount numeric)
WHERE p.id = x.id;

Главный плюс в том, что приложение передаёт один JSON-параметр, а вся пакетная обработка происходит внутри базы одним запросом.

🔥 Такой приём убирает циклы в коде, уменьшает количество запросов к базе и делает массовые операции намного чище.

➡️ SQL Ready | #совет

Разбираем почему ORDER BY RANDOM() на больших таблицах не лучшая идея!

Если нужно вытащить случайные строки из таблицы, многие пишут так, например в PostgreSQL:

SELECT *
FROM products
ORDER BY RANDOM()
LIMIT 10;

На первый взгляд всё отлично: перемешали строки и взяли первые 10. Но под капотом всё не так красиво. Обычно база читает много строк, а часто вообще всю таблицу, затем вычисляет случайное значение для каждой строки, сортирует результат и только после этого применяет LIMIT.

То есть даже если нужна всего одна строка:

SELECT *
FROM products
ORDER BY RANDOM()
LIMIT 1;

на большой таблице это всё равно может оказаться тяжёлым запросом. Если строк миллионы, начинаются проблемы с CPU, памятью, сортировками и latency. Индексы здесь обычно не помогают.

Один из более дешёвых вариантов — случайный выбор через id:

SELECT *
FROM products
WHERE id >= 1 + FLOOR(RANDOM() * (SELECT MAX(id) FROM products))::int
ORDER BY id
LIMIT 1;

Этот вариант уже может использовать индекс по id. Но есть нюанс: если после удалений в id много дырок, распределение будет неидеальным.

Например:

id
1
2
3
10000
10001

В таком случае чаще будет выпадать первая существующая строка после большого разрыва — здесь это 10000. То есть выборка получается смещённой.

Ещё один вариант — случайный OFFSET:

SELECT *
FROM products
OFFSET FLOOR(RANDOM() * (SELECT COUNT(*) FROM products))::int
LIMIT 1;

Звучит неплохо. Но у OFFSET тоже есть проблема: чем больше offset, тем больше строк базе придётся пропустить. Плюс в PostgreSQL COUNT(*) на большой таблице тоже может быть дорогой операцией.

В PostgreSQL есть ещё TABLESAMPLE:

SELECT *
FROM products TABLESAMPLE SYSTEM (1);

Или:

SELECT *
FROM products TABLESAMPLE BERNOULLI (1);

На больших таблицах это часто работает заметно быстрее. Но важно понимать: TABLESAMPLE выбирает примерный процент таблицы, а не конкретное количество строк.

Если нужно, например, 10 строк, обычно добавляют LIMIT:

SELECT *
FROM products TABLESAMPLE SYSTEM (1)
LIMIT 10;

Но и тут есть нюанс: если sample слишком маленький, запрос может вернуть меньше 10 строк.

И здесь тоже есть компромисс между скоростью и качеством случайной выборки. SYSTEM работает быстрее, но выбирает данные блоками, поэтому распределение менее равномерное. BERNOULLI ближе к построчной случайной выборке, но обычно дороже. В общем, мысль простая:

ORDER BY RANDOM()

выглядит красиво и удобно. Но на больших таблицах это один из тех запросов, которые начинают стоить очень дорого.

🔥 Именно такие простые запросы часто становятся причиной деградации производительности в продакшн.

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

Почему оконные функции могут давать неверный результат из-за RANGE вместо ROWS!

Одна из самых неприятных особенностей window functions — frame по умолчанию. Запрос выглядит корректно, проходит проверку глазами, но накопительная сумма может считаться совсем не так, как ожидает разработчик.

Особенно часто это встречается там, где важен порядок операций: расчёт балансов, транзакции, аналитика событий и любые накопительные показатели.

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

payments(id, created_at, amount)

Допустим, нужно получить обычный running total — сумму всех предыдущих платежей до текущей строки.

Запрос выглядит очевидно:

SELECT
    id,
    created_at,
    amount,
    SUM(amount) OVER (
        ORDER BY created_at
    ) AS running_total
FROM payments;

Логика кажется простой: первая строка берёт свой amount, вторая прибавляет своё значение к предыдущей сумме, третья делает то же самое. То есть ожидается: 100 — 300 — 600. Но у оконных функций есть скрытая настройка — frame.

Если после ORDER BY не указать его явно, SQL использует значение по умолчанию:

RANGE BETWEEN UNBOUNDED PRECEDING
AND CURRENT ROW

И именно здесь появляется разница между ожиданием и реальным результатом. RANGE работает не по физическому положению строк, а по значениям сортировки. То есть база смотрит на поле из ORDER BY и объединяет строки с одинаковым значением в одну логическую группу.

Например:

id=1, created_at='2026-01-01 10:00:00', amount=100
id=2, created_at='2026-01-01 10:00:00', amount=200
id=3, created_at='2026-01-01 11:00:00', amount=300

Здесь первые две записи имеют одинаковое время. Для человека это две разные операции. Но для RANGE они являются одной группой, потому что значение сортировки совпадает.

При таком запросе:

SUM(amount) OVER (
    ORDER BY created_at
)

результат будет:

300
300
600

Почему? Потому что при расчёте первой строки RANGE уже включает обе записи с одинаковым created_at. Получается: 100 + 200 = 300. Поэтому первая строка сразу показывает итог двух операций. Это не ошибка SQL, это стандартное поведение RANGE.

Но чаще всего для накопительных сумм ожидается другое поведение: каждая строка должна учитываться отдельно. Для этого используется ROWS, который работает именно с физическими строками окна.

Он не смотрит, одинаковые ли значения сортировки у соседних строк. Для него важен порядок строк после сортировки. Например:

SELECT
    id,
    created_at,
    amount,
    SUM(amount) OVER (
        ORDER BY created_at, id
        ROWS BETWEEN UNBOUNDED PRECEDING
        AND CURRENT ROW
    ) AS running_total
FROM payments;

Теперь база получает явную инструкцию: сначала отсортировать записи, затем считать накопление строка за строкой.

Результат становится ожидаемым:

100
300
600

Ещё один важный момент — сама сортировка. Даже если используется ROWS, одного created_at может быть недостаточно.

Если несколько событий произошли в одну секунду, SQL не обязан выбирать между ними определённый порядок. Например:

id=1, created_at='10:00:00', amount=100
id=2, created_at='10:00:00', amount=200

Какая операция должна идти первой? Без дополнительного поля ответа нет. Поэтому обычно добавляют уникальный идентификатор:

ORDER BY created_at, id

Теперь порядок строк становится однозначным, а результат расчёта стабильным.

RANGE удобен, когда нужно работать с группами одинаковых значений сортировки. ROWS нужен, когда важен порядок конкретных строк. Для обычного running total почти всегда стоит явно указывать ROWS.

🔥 Вывод: если cumulative sum показывает одинаковые значения на нескольких строках подряд — проверьте ORDER BY и frame окна. Чаще всего причина в том, что ожидали ROWS, а получили поведение RANGE.

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

📂 Напоминалка по SQL Roadmap!

Например, сначала изучают основы SQL и работу с таблицами, затем переходят к JOIN, сложным запросам, подзапросам и оконным функциям, а дальше — к проектированию баз данных, транзакциям и оптимизации.

На картинке — путь изучения от базового уровня до продвинутого: основные команды, структура базы данных, работа с данными, производительность запросов и др.

Сохрани, чтобы не потерять!

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

😒 Официальная библиотека промптов для Claude от Anthropic

Разработчики из Anthropic обновили и структурировали масштабный хаб готовых запросов для своей языковой модели. База создана для того, чтобы пользователи могли выжать максимум из Claude при решении прикладных и технических задач, не тратя время на самостоятельный подбор формулировок.

⚡️Внутри собраны сотни шаблонов под самые разные сценарии:

🟦Для безопасности: готовые конструкции для проверки кода на уязвимости и анализа граничных условий работы алгоритмов.

🟦Для разработчиков: шаблоны для глубокого ревью кода, автоматического поиска багов, рефакторинга, написания юнит-тестов и проектирования архитектуры.

🟦Для автоматизации и менеджмента: промпты под стратегическое планирование, парсинг неструктурированных данных, генерацию технической документации и выстраивание логики для ИИ-агентов.

Каждый шаблон снабжен подробным разбором: авторы пошагово объясняют, почему выбрана именно такая структура запроса, как модель интерпретирует переменные и как правильно передавать контекст. Поскольку библиотека официальная, все промпты оптимизированы под особенности контекстного окна и логику мышления последних моделей семейства Claude.

❤️‍🩹Сохраняйте в закладки и внедряйте в свои рабочие процессы.

Нейросети отлично автоматизируют рутину и помогают искать уязвимости, но управлять ими может только тот, кто понимает саму базу и суть киберугроз.

Если вы хотите заложить мощный фундамент начните с нашего бесплатного курса (его прошли уже 1108 человек!).

🟦Разберетесь, как работают кибератаки и как грамотно защитить свои данные.

🟦Познакомитесь с направлениями и профессиями в кибербезопасности, чтобы выбрать свой трек.

🟦Получите скидку, если решите продолжить обучение в CyberYozh Academy.

👉 Начните бесплатно прямо сейчас
🦔 CyberYozh

В PostgreSQL уникальность можно проверять не для всей таблицы, а только для части строк!

Допустим, у вас есть мягкое удаление пользователей:

SELECT email, deleted_at
FROM users;

После удаления запись остаётся в таблице, но появляется дата удаления.

Обычный уникальный индекс создаст проблему:

CREATE UNIQUE INDEX users_email_uniq
ON users (email);

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

Решение — частичный уникальный индекс:

CREATE UNIQUE INDEX users_active_email_uniq
ON users (email)
WHERE deleted_at IS NULL;

Теперь PostgreSQL будет проверять уникальность только среди активных пользователей.

Удалённые записи перестают участвовать в проверке.

Точно так же можно хранить:

CREATE UNIQUE INDEX one_draft_per_user
ON posts (user_id)
WHERE status = 'draft';

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

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

➡️ SQL Ready | #совет

🐱 PostgreSQL Cheat Sheet — удобная шпаргалка по PostgreSQL!

Этот репозиторий собрал самые важные команды и конструкции PostgreSQL в одном месте. Здесь можно быстро вспомнить синтаксис запросов, работу с таблицами, индексами, представлениями, функциями, транзакциями и др. Такая шпаргалка особенно полезна во время работы или подготовки к собеседованию.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

DEFERRABLE constraints — проверяй связи в конце транзакции, а не после каждой строки!

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

BEGIN;

INSERT INTO payments (id, order_id)
VALUES (1, 100);

INSERT INTO orders (id)
VALUES (100);

COMMIT;

Обычный FOREIGN KEY проверяется сразу, поэтому первый INSERT упадёт, если заказа 100 ещё нет.

DEFERRABLE INITIALLY DEFERRED переносит проверку ограничения на момент COMMIT, поэтому база смотрит не на промежуточное состояние, а на итог транзакции.

SET CONSTRAINTS ALL IMMEDIATE;

При необходимости проверку можно принудительно выполнить раньше прямо внутри транзакции.

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

🔥 Фишка в том, что ты не отключаешь целостность данных, а просто переносишь момент проверки.

➡️ SQL Ready | #совет

👍 Годная статья вышла на Хабре: «Шардированный не значит распределённый, что важно знать, когда PostgreSQL становится мало»!

В этой статье:
• Объясняется разница между шардированным PostgreSQL и настоящими распределёнными СУБД;
• Разбирается, почему Citus и похожие решения не дают полноценные ACID-гарантии для multi-shard транзакций;
• Показывается, как работают 2PC, distributed snapshot и уровни изоляции транзакций;
• На примерах объясняются проблемы consistency и eventual consistency в распределённых системах;

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

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

📂 Напоминалка по генерации уникальных ID в SQL и распределённых системах!

Например, Auto-Increment подходит для простых SQL-проектов, где одна база данных управляет последовательностью записей, а Snowflake/UUID чаще используют в высоконагруженных системах с микросервисами, где требуется генерация ID без единой точки отказа.

На картинке — 5 основных подходов к созданию уникальных идентификаторов.

Сохрани, чтобы не потерять!

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

Обычное сравнение через = и != ломается, как только появляется NULL!

old_value IS DISTINCT FROM new_value

В SQL NULL никогда не равен даже другому NULL, поэтому сравнение начинает вести себя не так, как ожидается.

SELECT
    NULL = NULL,
    NULL != NULL;

Оба выражения вернут не TRUE и не FALSE, а NULL. Именно из-за этого часто ломается логика сравнения.

SELECT *
FROM users
WHERE old_email != new_email;

Кажется, что запрос покажет все изменённые email. Но если одно из значений NULL, строка может просто не попасть в выборку.

Для таких случаев в PostgreSQL есть специальный оператор.

SELECT *
FROM users
WHERE old_email IS DISTINCT FROM new_email;

Теперь NULL корректно участвует в сравнении. PostgreSQL считает NULL обычным сравниваемым состоянием.

NULL IS DISTINCT FROM NULL        -- false
NULL IS DISTINCT FROM 'test'      -- true
'a'  IS DISTINCT FROM 'b'         -- true

Пригодится в аудитах изменений, UPSERT-логике, ETL и триггерах, где важно понять: значение реально изменилось или нет.

🔥 Оператор, который убирает большое количество багов при работе с NULL.

➡️ SQL Ready | #совет

📂 Напоминалка по шардингу данных!

Например, range-based шардинг делит данные по диапазонам значений, hash-based — распределяет записи через хэш-функцию, а consistent hashing помогает минимизировать перераспределение данных при добавлении новых нод.

На картинке — 4 алгоритма шардинга, которые полезно знать при проектировании масштабируемых систем и высоконагруженных баз данных.

Сохрани, чтобы не потерять!

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

Почему CONCAT_WS в PostgreSQL часто лучше обычной конкатенации строк!

Есть такие SQL-функции, которые вроде бы выглядят слишком простыми, чтобы о них писать отдельный пост. Но именно они часто убирают кучу мелких проблем в реальных проектах, CONCAT_WS — хороший пример.

Когда работаешь с тестовыми данными, кажется, что собрать строку очень просто. Есть имя, фамилия, отчество — соединяем их через пробел и получаем красивый результат.

Обычно первый вариант выглядит так:

SELECT
    first_name || ' ' || middle_name || ' ' || last_name AS full_name
FROM users;

На первый взгляд всё нормально. Но потом база начинает жить настоящими данными. У одного пользователя нет отчества. У другого не заполнена фамилия. После миграции часть полей приходит пустыми. И вот здесь простой запрос начинает вести себя не так, как ожидает разработчик.

Например:

first_name = 'John'
middle_name = NULL
last_name = 'Smith'

Кажется логичным получить:

John Smith

Но PostgreSQL вернёт:

NULL

Причина в том, что NULL — это не пустое значение. Это отсутствие значения. При обычной конкатенации строк неизвестная часть делает неизвестным весь результат.

Конечно, можно начать добавлять COALESCE:

SELECT
    first_name || ' ' ||
    COALESCE(middle_name || ' ', '') ||
    last_name
FROM users;

Для двух-трёх полей это ещё нормально. Но в реальном запросе таких частей может быть намного больше: адрес, название компании, описание товара, дополнительные параметры.

И постепенно вместо простой сборки строки появляется большая конструкция из проверок.

В PostgreSQL для таких задач есть более удобный вариант:

SELECT
    CONCAT_WS(
        ' ',
        first_name,
        middle_name,
        last_name
    ) AS full_name
FROM users;

CONCAT_WS расшифровывается как "concatenate with separator". Первый аргумент — разделитель, который нужно использовать между значениями.

Главная особенность в том, что функция сама пропускает NULL. То есть:

John + NULL + Smith

превратится в:

John Smith

а не в строку с лишним пробелом или неожиданный NULL.

На практике это особенно удобно, когда собираете данные для отображения пользователю. Например, адрес:

Germany, Berlin, Alexanderplatz 10

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

Но есть нюанс, который часто забывают. CONCAT_WS пропускает NULL, но пустую строку считает настоящим значением.

Например, после загрузки данных из CSV можно получить:

middle_name = ''

Для пользователя это выглядит так же, как отсутствие значения. Но PostgreSQL различает эти случаи. В результате можно получить: John Smith с двойным пробелом.

Поэтому в системах, где данные приходят из разных источников, часто сначала нормализуют значения:

NULLIF(middle_name, '')

После этого пустые строки становятся NULL, и CONCAT_WS уже работает предсказуемо. На небольших примерах это кажется мелочью. Но когда у тебя несколько миллионов записей и данные собираются из разных сервисов, именно такие детали начинают влиять на качество данных и количество лишнего кода.

🔥 CONCAT_WS — хороший пример того, как правильный инструмент делает SQL проще. Если нужно собрать строку из нескольких необязательных полей — часто лучше использовать её, чем вручную обрабатывать каждый NULL.

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

Используй RETURNING как временную таблицу!

Многие после UPDATE делают отдельный SELECT, чтобы получить изменённые данные.

Но PostgreSQL уже умеет вернуть результат изменения через RETURNING.

UPDATE orders
SET status = 'paid',
    paid_at = now()
WHERE id = 1001
RETURNING id, status, paid_at;

Один запрос вместо двух. RETURNING можно сразу передавать дальше.

Например, обновили заказ и сразу записали историю изменения:

WITH changed AS (
    UPDATE orders
    SET status = 'cancelled'
    WHERE id = 1001
    RETURNING id, status
)
INSERT INTO order_history(order_id, new_status)
SELECT id, status
FROM changed;

Без промежуточных переменных и без повторного поиска строки.

Также можно использовать это для атомарного переноса данных:

WITH moved AS (
    DELETE FROM queue
    WHERE id = 55
    RETURNING *
)
INSERT INTO archive_queue
SELECT *
FROM moved;

🔥 Получается "забрать строку и положить в другую таблицу" одной транзакционной операцией. Часто заменяет сложный код в сервисах и убирает лишние запросы к базе.

➡️ SQL Ready | #совет

✍️ PostgreSQL Wiki — справочник и документация по PostgreSQL!

На сайте опубликованы статьи, руководства, инструкции и практические материалы по работе с одной из самых популярных СУБД. Здесь можно найти информацию по установке, настройке, администрированию, оптимизации производительности, репликации, резервному копированию, расширениям и др.

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

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