SQL Ready | Базы Данных

Как получить «последнюю запись на группу»? Очень частая задача - взять последнюю запись на пользователя, заказ, сущность. Многие делают это с ROW_NUMBER(), хотя Postgres умеет проще:

SELECT DISTINCT ON (user_id) *
FROM orders
ORDER BY user_id, created_at DESC;

DISTINCT ON оставляет первую строку в рамках группы, а порядок задаётся через ORDER BY:

ORDER BY user_id, created_at DESC

Так первой будет именно самая свежая запись. Если возможны одинаковые created_at, лучше явно добавить тай-брейкер:

ORDER BY user_id, created_at DESC, id DESC

Если нужно выбрать конкретные поля и избежать SELECT *, просто укажите нужные колонки:

SELECT DISTINCT ON (user_id)
       user_id, id, created_at
FROM orders
ORDER BY user_id, created_at DESC, id DESC;

Выражения из DISTINCT ON (...) обязаны быть левым префиксом ORDER BY, иначе Postgres выдаст ошибку. 🔥 Такой запрос часто читается проще, чем ROW_NUMBER(), и при подходящем индексе (user_id, created_at DESC, id DESC) может давать отличный план выполнения. ➡️ SQL Ready | #совет

Секрет, который делит январь на «до» и «после» в карьере. В январе есть два типа соискателей:

99% — обновляют резюме, рассылают его в 100 компаний и ждут. Они получают тишину или вежливые отказы. 1% — используют «окно возможностей». Они знают, что мало просто найти вакансии. Нужно пройти так, чтобы рекрутер не мог вас пропустить.

Разница не в опыте. Разница в методе. Мы в @mathcareer — про метод. Мы не даём «советы», а разбираем систему: как читать вакансию между строк, что писать в сопроводительном письме, которое откроет двери, и как вести переговоры. Хотите перейти из 99% в 1%? 👉 Всё уже разложено по полочкам здесь: https://t.me/+v5AE1DRA7L04MGVi

🖥 Поиск дубликатов и ранжирование данных! Шпаргалка по оконным функциям и агрегатам для нумерации строк, поиска и анализа дубликатов, ранжирования результатов и аккуратного удаления лишних записей. Используется при очистке данных, аналитических запросах, построении рейтингов и подготовке данных к миграциям и отчётности. ➡️ SQL Ready | #шпора

Настроил чат-бота за пару часов → заработал 9 000₽. Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу. А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени. Разница в зарплате: 200 тысяч. И нет — не надо ничего программировать. Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе. Без опыта. За 3-4 часа. 💡 Суть проста: Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги. В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно. Всё, что нужно для старта — запустить бота 👉 @other_digital_bot Там пошаговый план как стартануть и гайд по клиентам. До 26 января вход бесплатный.

💡 На Хабре вышла мега годная статья: «Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99%»! В этой статье: • О системе обработки огромного потока форм — от поиска до подачи объявлений; • Подробно объясняется, зачем команде нужен уровень надёжности SLI 99.99%; • Описаны оригинальные подходы к версионированию данных, изоляции изменений; • Приводятся реальные схемы работы с SQL/NoSQL, кэшами и стратегиями graceful degradation при отказах.

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

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

Знали, что агрегаты можно фильтровать без CASE и подзапросов? Многие пишут COUNT(CASE WHEN ...), хотя в SQL (например, в PostgreSQL) есть более декларативный способ - FILTER. Фильтрация применяется к агрегатной функции, а не ко всей выборке:

COUNT(*) FILTER (WHERE status = 'paid')

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

COUNT(*) FILTER (WHERE status = 'failed')

Оптимизатор обычно сводит такой запрос к линейному плану. FILTER работает не только с COUNT, но и с другими агрегатами:

SUM(amount) FILTER (WHERE status = 'paid')

🔥 FILTER выразит намерение напрямую: агрегат считает только нужные строки, без лишней логики. ➡️ SQL Ready | #совет

Изоляция рунета ближе, чем ты думаешь

Loading … ██████████████] 99%

Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.

Email должен быть уникальным только для активных пользователей? Большинство реализуют это проверками в коде, SELECT перед INSERT, транзакциями или триггерами. PostgreSQL умеет делать это на уровне индекса:

INSERT INTO users (email) VALUES ('a@b.com');

Сработает, если активного пользователя с таким email ещё нет:

UPDATE users SET deleted_at = now() WHERE email = 'a@b.com';

Теперь email снова можно использовать для активных, без физического удаления строк. 🔥 Partial UNIQUE index — отличный способ фиксировать правила прямо в PostgreSQL. ➡️ SQL Ready | #совет

🚀 Yandex B2B Tech запускает сервис Managed Sharded PostgreSQL для горизонтального масштабирования PostgreSQL PostgreSQL — самая популярная open-source СУБД, которой сегодня пользуются 55,6% профессиональных разработчиков. Но одна из главных её ограничений — отсутствие встроенного горизонтального масштабирования, что критично при обработке больших объемов данных. Yandex B2B Tech решила эту задачу, запустив сервис , который позволяет шардировать PostgreSQL — то есть распределять данные по нескольким серверам. Это ускоряет работу систем, снижает риски и сокращает время вывода продуктов на рынок в 3-4 раза. Технология уже проверена в реальных проектах Яндекса, таких как Яндекс ID, Яндекс Пэй и Едадил, а также успешно используется внешними клиентами. Managed Sharded PostgreSQLдоступен на облачной платформе Yandex Cloud и помогает банкам и ритейлерам обрабатывать миллионы транзакций быстрее и надежнее. Подробнее — ссылка

👍 DataLemur — задачи для практики и подготовки к собеседованиям! На сайте собраны вопросы разного уровня сложности: от базовых запросов до задач с JOIN, GROUP BY, подзапросами и оконными функциями. Формат ориентирован на реальные кейсы, такие задачи часто встречаются в работе и на собеседованиях. Удобный ресурс, чтобы закрепить знания. 📌 Оставляю ссылочку: datalemur.com ➡️ SQL Ready | #ресурс

Partial index по стабильному селективному срезу! В PostgreSQL частичный индекс особенно эффективен, когда в запросах регулярно повторяется один и тот же селективный предикат WHERE, а цель — быстро получить последние N записей по времени. Таблица:

audit_logs(id, service, level, created_at, payload JSONB)

Индекс под узкий сегмент:

CREATE INDEX idx_billing_errors
ON audit_logs (created_at DESC)
WHERE service = 'billing' AND level = 'error';

Меньший размер индекса снижает нагрузку на buffer cache, уменьшает вероятность bloat и объём фонового обслуживания, а операции с индексом требуют меньше ресурсов. Запрос за последними ошибками за сутки:

SELECT id, created_at, payload
FROM audit_logs
WHERE service = 'billing'
  AND level = 'error'
  AND created_at > NOW() - INTERVAL '1 day'
ORDER BY created_at DESC
LIMIT 15;

Связка ORDER BY created_at DESC + LIMIT позволяет планировщику сделать Index Scan и остановиться рано, как только найдено нужное количество строк. index-only scan возможен только если все нужные колонки читаются из индекса, и страницы таблицы помечены all-visible (visibility map). Если вам действительно нужен index-only для части полей, можно использовать INCLUDE:

CREATE INDEX idx_billing_errors_top
ON audit_logs (created_at DESC)
INCLUDE (id)
WHERE service = 'billing' AND level = 'error';

Частичный индекс по JSONB boolean-предикату (когда совпадающих строк мало и условие повторяется):

CREATE INDEX idx_critical_errors
ON audit_logs (created_at DESC)
WHERE level = 'error'
  AND payload @> '{"critical": true}';

И быстрый top-N:

SELECT id, service, created_at
FROM audit_logs
WHERE level = 'error'
  AND payload @> '{"critical": true}'
ORDER BY created_at DESC
LIMIT 10;

🔥 Частичные индексы — простой и экономный инструмент для повторяемого узкого среза + быстрого top-N по времени. ➡️ SQL Ready | #практика

Пройти видеоверификацию на бирже или фармить донаты на OnlyFans 😍 Создать виртуальную личность и устроиться на работу онлайн. Это 1 из 1000 способов оседлать ИИ. А научиться работать с этим можно в этом канале. Там уже слили: – Как получить много генераций [гайд] – Промты, улучшающие ответы ChatGPT в 10 раз [скопировать] – Дикие способы заработка на ИИ [читать] ⚡️ Сохраняйте, это мастхев на 2026 год: @neiropulse

❤️ Нашёл замечательную статью на Хабре: «Курс молодого бойца PostgreSQL»! В этой статье: • Автор шаг за шагом показывает, как использовать ключевые возможности PostgreSQL; • Приводятся понятные примеры SQL-запросов с объяснением, когда и почему применять те или иные конструкции; • Рассматриваются полезные трюки - преобразование типов, агрегации и работа с массивами; • Все примеры можно сразу запускать.

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

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

IS NOT DISTINCT FROM - равенство без NULL! Обычное сравнение через = ломается, если возможен NULL:

SELECT *
FROM users
WHERE email = 'admin@example.com';

Эта проверка никогда не вернёт строки с NULL, даже если логически они равны:

SELECT *
FROM users
WHERE email IS NOT DISTINCT FROM NULL;

IS NOT DISTINCT FROM считает NULL = NULL и работает как настоящее равенство:

sql
SELECT *
FROM users
WHERE (email, phone)
IS NOT DISTINCT FROM ('a@b.com', NULL);

Работает и для составных сравнений, без OR … IS NULL. 🔥 IS NOT DISTINCT FROM - способ сравнивать значения, когда NULL допустимое состояние, а не исключение. ➡️ SQL Ready | #совет

👩‍💻 В сеть вывалилась гигантская куча курсов и книг от топовых IT‑школ Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё! • 1612 ГБ — DevOps • 1402 ГБ — Python • 1300 ГБ — C, C++ • 1815 ГБ — Frontend • 1515 ГБ — Backend • 898 ГБ — ИБ, Хакинг • 996 ГБ — Kotlin, Swift • 212 ГБ — JavaScript • 315 ГБ — Flutter • 820 ГБ — Go, PHP • 419 ГБ — Java, Rust • 648 ГБ — GameDev • 517 ГБ — Windows, Linux • 998 ГБ — Дизайн (UX/UI) • 617 ГБ — Нейросети (ML/RL) • 546 ГБ — БД (SQL & NoSQL) • 687 ГБ — Аналитика данных • 115 ГБ — QA-тестирование Подписывайся и не плати за то, что можно получить бесплатно

📂 Напоминалка для работы с SQL JOIN! Например, INNER JOIN возвращает только совпадающие строки из двух таблиц, а LEFT JOIN позволяет получить все записи из основной таблицы, даже если связанной записи нет. На картинке — 4 самых используемых типа SQL JOIN, которые постоянно встречаются в рабочих запросах. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

🖥 INDEX ONLY SCAN — когда SELECT не идёт в таблицу! Когда в запросе нужны 2-3 конкретных поля, база может отдать их прямо из индекса, не трогая таблицу. Это особенно важно для тяжёлых таблиц, где каждый лишний lookup - потеря времени. Сегодня в гайде:

• Как запрос выполняется только из индекса; • Как убедиться, что таблица не читается (Heap Fetches: 0 в плане); • Как проектировать индексы, чтобы покрывать SELECT полностью.

Покрывающий индекс устраняет table lookup, снижает I/O и делает чтение стабильным при росте данных. ➡️ SQL Ready | #гайд