Разбор 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 | #совет

❤️‍🔥"Это разъ*бный сетап, бро!" 😤

Так сказал мой друг из Африки, когда увидел этот стол)
Не знаю уж че за сетап, меня зовут Саша и качественную необычную мебель из натурального дерева я делаю уже больше 12-ти лет, столько же занимаюсь и темой здоровья.

Когда я услышал, что до 10% смертности связано с сидячим образом жизни, меня это поразило и я задался целью делать максимально функциональные и полезные рабочие пространства, ибо геморрой в 30 это конечно довольно нишево, но все же сомнительно 😂

Ну а собрать такой комплект под свои задачи и при этом сразу прикинуть цены вы можете в удобном Mini App конструкторе ➕

Разбираем почему 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 | #практика

0nix — Новая экосистема для профи.

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

🛡Для кибербезопасников: Threat Intelligence, Осинтеров , Геоинтеров, Red Team, разработчиков инструментов. Ваша аудитория ждет ваши услуги.

💻 Для разработчиков и дизайнеров: Отдельные разделы с заказами на разработку, дизайн и графику. Портфолио — в топ!

Условия для первых участников: Минимальные комиссии на сделки, быстрый арбитраж и модерация.

Регистрируйся и забирай свою скидку на привилегии уже сегодня → 0nix.cc , 0nix.top

Почему оконные функции могут давать неверный результат из-за 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 | #ресурс

IT мероприятия 🤘

Всё самое интересное для карьеры в IT: митапы, хакатоны, конференции, стажировки и обучение.

Подписывайся 🤘

1. Москва
2. Санкт-Петербург
3. Для стажеров и студентов

Обычное сравнение через = и != ломается, как только появляется 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 | #ресурс

🤔 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 | #практика