Используй 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 | #ресурс

🤔 Learn PostgreSQL — информативное руководство!

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

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

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

Почему ROW_NUMBER(), RANK() и DENSE_RANK() в SQL дают разный результат!

Есть такие оконные функции в SQL, которые выглядят почти одинаково, но используются для разных задач. ROW_NUMBER(), RANK() и DENSE_RANK() все умеют добавлять номера к строкам, но поведение меняется, когда в данных появляются одинаковые значения.

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

Например, есть таблица с результатами:

score
-----
100
100
90
80

Если нужно просто пронумеровать строки после сортировки, обычно используют ROW_NUMBER():

SELECT
    score,
    ROW_NUMBER() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

Результат:

score | position
------+---------
100   | 1
100   | 2
90    | 3
80    | 4

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

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

Если два пользователя набрали одинаковое количество баллов, обычно ожидается, что они займут одинаковое место. Для такой задачи используется RANK():

SELECT
    score,
    RANK() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

Результат:

score | position
------+---------
100   | 1
100   | 1
90    | 3
80    | 4

RANK() учитывает одинаковые значения и присваивает им одинаковый номер. Но после одинаковых результатов появляются пропуски. В примере выше два участника заняли первое место, поэтому следующий результат получает третье место.

Иногда такое поведение является правильным. Например, в спортивных рейтингах, где нужно учитывать фактическое количество участников с одинаковым результатом. Но бывают случаи, когда пропуски не нужны. Тогда используется DENSE_RANK():

SELECT
    score,
    DENSE_RANK() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

Результат:

score | position
------+---------
100   | 1
100   | 1
90    | 2
80    | 3

DENSE_RANK() работает похоже на RANK(), но продолжает нумерацию без пропусков. Получается простое правило: ROW_NUMBER() — когда каждая строка должна получить свой уникальный номер; RANK() — когда одинаковые значения должны иметь одинаковое место, а пропуски после них допустимы; DENSE_RANK() — когда одинаковые значения должны иметь одинаковое место, но нумерация должна идти без пропусков.

Есть ещё один практический момент, который часто забывают при использовании ROW_NUMBER(). Если несколько строк имеют одинаковое значение для сортировки:

SELECT
    id,
    score,
    ROW_NUMBER() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

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

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

SELECT
    id,
    score,
    ROW_NUMBER() OVER (
        ORDER BY score DESC, id
    ) AS position
FROM results;

🔥 ROW_NUMBER(), RANK() и DENSE_RANK() решают похожую задачу, но предназначены для разных сценариев. Главное — понимать, нужна ли вам обычная нумерация строк или именно логика рейтинга.

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

📂 Напоминалка по SQL JOIN и объединению данных!

Например, INNER JOIN возвращает только совпадающие записи, LEFT/RIGHT JOIN сохраняют данные одной из сторон, а FULL JOIN объединяет полный набор данных из обеих таблиц. Дополнительные проверки через NULL позволяют находить отсутствующие связи между сущностями.

На картинке — основные типы JOIN и визуальное представление того, какие строки попадут в результат выполнения запроса.

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

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

🐱 Полезную статью нашёл на Хабре: «PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря»!

В этой статье:
• Рассматриваются возможности PostgreSQL, которые помогают решать типовые backend-задачи на уровне базы;
• Разбираются эффективные инструменты для работы с очередями, запросами, индексами и поиском;
• Показывается, как использовать встроенные механизмы PostgreSQL для повышения производительности приложений.

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

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

Индексы по выражениям — ускоряем поиск по вычисляемым значениям!

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

Таблица:

users(id, email)

Создадим индекс на email:

CREATE INDEX idx_users_email
ON users(email);

Теперь простой поиск по точному значению использует этот индекс:

SELECT *
FROM users
WHERE email = 'test@mail.com';

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

SELECT *
FROM users
WHERE LOWER(email) = 'test@mail.com';

Проблема в том, что PostgreSQL должен применить LOWER() к каждой строке, а потом сравнить результат. Обычный индекс по email для такого условия уже не подходит.

Решение — создать индекс не на колонку, а на результат выражения:

CREATE INDEX idx_users_lower_email
ON users(LOWER(email));

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

EXPLAIN ANALYZE
SELECT *
FROM users
WHERE LOWER(email) = 'test@mail.com';

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

CREATE INDEX idx_orders_year
ON orders(EXTRACT(YEAR FROM created_at));

Теперь запросы по этому выражению могут использовать индекс вместо полного прохода таблицы.

Индекс нужно создавать под реальные запросы. Лишние увеличивают время INSERT/UPDATE и занимают место.

🔥 Индексы по выражениям полезны, когда одно и то же вычисление постоянно используется в WHERE, JOIN или ORDER BY.

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

😍 CitForum Database — большая база материалов по SQL и СУБД!

На сайте собрана крупная библиотека материалов по базам данных: SQL, проектирование БД, транзакции, индексы, оптимизация запросов и администрирование различных СУБД. Здесь можно найти статьи, учебные пособия, техническую документацию и обзоры по PostgreSQL, MySQL, Oracle, Microsoft SQL Server и другим системам управления базами данных.

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

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

📂 Напоминалка по выбору NoSQL баз данных для проектов!

Например, MongoDB подходит для работы с гибкими документными структурами, Redis — для высокопроизводительного кэширования и хранения данных в памяти, а Cassandra — для распределённых систем с огромными объёмами данных и высокой доступностью.

На картинке — сравнение популярных NoSQL решений, их особенностей и основных сценариев использования: от поиска и аналитики до IoT, социальных сетей, e-commerce и real-time приложений.

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

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

Вычисляемые значения на стороне PostgreSQL!

Если значение полностью зависит от других колонок, не обязательно считать его перед каждым INSERT и UPDATE.

PostgreSQL умеет делать это сам и всегда гарантирует корректный результат.

INSERT INTO orders(price, quantity)
VALUES (100, 3);

SELECT total
FROM orders
WHERE id = 1;

Поле total заполнится автоматически. Его нельзя случайно забыть обновить или вычислить по старой формуле.

UPDATE orders
SET quantity = 5
WHERE id = 1;

SELECT total
FROM orders
WHERE id = 1;

После изменения исходных данных значение пересчитается автоматически.

ALTER TABLE products
ADD COLUMN search_name text
GENERATED ALWAYS AS (lower(name)) STORED;

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

🔥 Если колонка полностью вычисляется из других колонок, пусть этим занимается PostgreSQL. Логику проще поддерживать, когда вычисление в одном месте.

➡️ SQL Ready | #совет

🧐 SQLler — интерактивный тренажёр для изучения SQL!

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

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

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

📂 Напоминалка по работе с данными: Pandas — Polars — SQL!

Например, groupby() в Pandas и Polars выполняет роль GROUP BY в SQL, merge() аналогичен JOIN, sort_values() заменяет ORDER BY, а unique() работает как SELECT DISTINCT.

На картинке — основные операции для работы с таблицами: загрузка данных, просмотр строк, фильтрация, сортировка, группировка, объединение таблиц, переименование и удаление колонок в Pandas, Polars и SQL.

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

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

Почему EXISTS в SQL часто лучше использовать для проверки наличия данных, чем COUNT(*)!

Одна из распространённых задач в SQL — определить, существует ли хотя бы одна запись, соответствующая заданному условию. Для этого иногда используют COUNT(*), хотя его основное назначение — вычисление количества строк, а не проверка факта существования данных.

Например, есть таблица пользователей:

id | email
---+-----------------
1  | user@test.com
2  | admin@test.com
3  | test@test.com

Проверка наличия пользователя через COUNT(*):

SELECT
    COUNT(*)
FROM users
WHERE email = 'user@test.com';

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

Для проверки факта существования данных лучше подходит EXISTS:

SELECT EXISTS (
    SELECT 1
    FROM users
    WHERE email = 'user@test.com'
);

EXISTS возвращает логическое значение: TRUE, если найдена хотя бы одна подходящая строка, и FALSE, если совпадений нет. При выполнении такого запроса оптимизатор базы данных может использовать стратегию с ранним завершением проверки после нахождения первого совпадения, так как дальнейший поиск для этой операции не имеет смысла.

Разница особенно заметна в больших таблицах и в часто выполняемых проверках внутри бизнес-логики: при создании пользователей, проверке связей между сущностями, наличии связанных данных и других условных операциях. Например, проверка наличия заказов пользователя через COUNT(*):

SELECT
    COUNT(*)
FROM orders
WHERE user_id = 100;

Этот запрос отвечает на вопрос: сколько заказов существует у пользователя.

Если требуется только проверить наличие хотя бы одного заказа:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 100
);

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

COUNT(*) остаётся правильным выбором, когда необходимо получить фактическое количество записей:

SELECT
    COUNT(*) AS orders_count
FROM orders
WHERE user_id = 100;

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

🔥 Важно понимать разницу: COUNT(*) отвечает на вопрос: сколько строк существует? EXISTS отвечает на вопрос: существует ли хотя бы одна строка? Выбор правильного оператора делает SQL-запросы более выразительными и лучше соответствует реальной задаче приложения.

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

🧐 SQL Murder Mystery — изучаем SQL через детективное расследование!

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

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

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

IS DISTINCT FROM — сравнение значений с NULL!

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

NULL <> 'new value'

Результатом выражения будет NULL, а не TRUE или FALSE. Это связано с трёхзначной логикой SQL: результат сравнения с неизвестным значением также является неизвестным.

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

column <> new_value
OR (column IS NULL AND new_value IS NOT NULL)
OR (column IS NOT NULL AND new_value IS NULL)

Оператор IS DISTINCT FROM решает эту задачу, выполняя сравнение с явным учетом NULL и всегда возвращая логическое значение. Пример обновления пользователя только при фактическом изменении email:

UPDATE users
SET email = :new_email
WHERE id = :id
  AND email IS DISTINCT FROM :new_email;

Если значения совпадают, строка обновлена не будет. Если одно значение содержит NULL, а другое — данные, оператор определит их как различные.

Оператор также корректно обрабатывает случай, когда оба значения равны NULL:

SELECT NULL IS DISTINCT FROM NULL;

Результат:

false

В логике IS DISTINCT FROM два значения NULL считаются одинаковыми, так как оба представляют отсутствие значения. Без использования данного оператора аналогичная проверка требует дополнительных условий:

email <> :new_email
OR (email IS NULL AND :new_email IS NOT NULL)
OR (email IS NOT NULL AND :new_email IS NULL)

IS DISTINCT FROM заменяет такую конструкцию одним выражением и делает сравнение nullable-полей более предсказуемым.

При обновлении сущностей через API, синхронизации данных и импорте часто возникает ситуация, когда передаётся полный объект, хотя часть полей не изменилась. Обычный запрос:

UPDATE users
SET
    email = :new_email,
    name = :new_name
WHERE id = :id;

выполнит обновление независимо от фактического изменения значений.

В PostgreSQL это приводит к созданию новой версии строки в рамках MVCC, увеличению объёма WAL, дополнительным вызовам триггеров и генерации ненужных событий при использовании репликации или систем обработки изменений. Более точный вариант:

UPDATE users
SET
    email = :new_email,
    name = :new_name
WHERE id = :id
  AND (
      email IS DISTINCT FROM :new_email
      OR name IS DISTINCT FROM :new_name
  );

Такой подход позволяет выполнять обновление только при изменении данных. Он применяется в API, системах синхронизации, импортерах данных и интеграционных процессах.

🔥 IS DISTINCT FROM — оператор, который обеспечивает корректное сравнение значений с NULL и помогает избегать лишних операций записи в базе данных.

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

📂 Напоминалка по порядку выполнения SQL-запросов!

Например, разработчик пишет запрос начиная с SELECT, но SQL-движок выполняет его иначе: сначала формирует источник данных через FROM, объединяет таблицы через JOIN, фильтрует записи через WHERE, группирует данные через GROUP BY и только после этого формирует итоговый результат.

На картинке — логический порядок выполнения SQL-операций.

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

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