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

Совет на ближайшие годы — идите в Data Science и ML Пока ИИ забирает работу у одних специалистов, другие строят на нём карьеру и зарабатывают всё больше. И вопрос уже не в том, изменит ли ИИ рынок, а в том, по какую сторону этих изменений окажетесь вы. DS/ML – один из самых прямых способов оказаться среди тех, кто на этом выигрывает А чтобы не тратить годы на хаотичное обучение – держите в подписках Data Portal. Там практикующие ML-инженеры понятным языком разбирают главное: новые модели, библиотеки, исследования, датасеты, гайды, курсы и практические кейсы. Подписывайтесь: @LLMScience

🖥 Oracle — агрегация данных и отчётность! Шпаргалка по агрегации данных и формированию отчётности в Oracle SQL: объединение значений с LISTAGG, выбор значений по рангу с KEEP (DENSE_RANK FIRST/LAST), построение промежуточных и общих итогов с ROLLUP и GROUPING SETS, а также идентификация уровней агрегации с помощью GROUPING и GROUPING_ID. Полезно для построения сводных выборок, многоуровневых отчётов и обработки агрегированных данных непосредственно средствами SQL. ➡️ SQL Ready | #шпора

Составные индексы: правила проектирования и типичные ошибки! Составные индексы используются для ускорения запросов по нескольким колонкам, но порядок полей внутри индекса напрямую влияет на его эффективность. Представим таблицу заказов, где часто выполняются запросы по пользователю и дате создания заказа.

CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    status VARCHAR(30),
    created_at TIMESTAMP NOT NULL,
    amount NUMERIC(10,2)
);

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

CREATE INDEX idx_orders_user
ON orders(user_id);

CREATE INDEX idx_orders_created_at
ON orders(created_at);

Для частого сценария поиска заказов конкретного пользователя за период лучше создать составной индекс:

CREATE INDEX idx_orders_user_created_at
ON orders(user_id, created_at);

Такой индекс эффективно работает для запросов, где используется первая колонка индекса или полный набор колонок.

SELECT *
FROM orders
WHERE user_id = 42
AND created_at >= '2026-01-01';

В B-tree индексе данные сначала сортируются по user_id, а внутри одинаковых значений user_id — по created_at. Поэтому СУБД быстро находит записи пользователя и затем выполняет поиск по диапазону дат. Также индекс будет использоваться:

SELECT *
FROM orders
WHERE user_id = 42;

Но он плохо подходит для поиска только по второй колонке:

SELECT *
FROM orders
WHERE created_at >= '2026-01-01';

Причина в структуре B-tree: данные сначала организованы по первой колонке индекса. Для такого запроса отдельный индекс по дате будет более подходящим:

CREATE INDEX idx_orders_created_at
ON orders(created_at);

Ещё одна распространённая ошибка — добавление большого количества колонок в индекс.

CREATE INDEX idx_orders_all_columns
ON orders(user_id, status, created_at, amount);

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

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE user_id = 42
AND status = 'paid'
ORDER BY created_at DESC;

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

CREATE INDEX idx_orders_user_status_created_at
ON orders(user_id, status, created_at DESC);

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

Оконный фрейм по группам значений! ROWS считает физические строки. GROUPS считает группы строк с одинаковым значением ORDER BY.

SELECT price,
       count(*) OVER (
           ORDER BY price
           GROUPS BETWEEN 1 PRECEDING AND 1 FOLLOWING
       )
FROM products;

Если по одной цене находится 50 товаров, вся эта пачка считается одной группой. Поэтому можно строить окна относительно соседних значений, не вычисляя dense_rank() и не добавляя ещё один уровень запроса. Ещё интереснее EXCLUDE, который можно использовать прямо внутри оконного фрейма:

SELECT id,
       avg(score) OVER (
           ORDER BY created_at
           ROWS BETWEEN 10 PRECEDING AND 10 FOLLOWING
           EXCLUDE CURRENT ROW
       ) AS neighbors_avg
FROM measurements;

Среднее здесь считается по соседним строкам, но текущая строка автоматически исключается.

SELECT price,
       sum(amount) OVER (
           ORDER BY price
           GROUPS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
           EXCLUDE GROUP
       )
FROM sales;

EXCLUDE GROUP исключит из расчёта всю текущую peer-группу, а не только одну строку. 🔥 GROUPS + EXCLUDE позволяют описывать сложные окна непосредственно в OVER, где обычно появляются dense_rank(), дополнительные CTE и self join. ➡️ SQL Ready | #совет

Хочешь заняться архитектурой, а вместо этого третий час пишешь одну и ту же типовую миграцию? Теперь это можно делегировать. CatCode - агент, который работает с проектом сам: пишет миграции, чинит запросы, гоняет тесты, пока ты занят чем-то более интересным. Доступны все топовые модели: 😒 Claude Opus 5 🤖 GPT-6 Astra 😐 Grok 4.6 и многие другие. Умный свитчер решит фоном, кому что отдать - рутину дешёвой модели, сложный таск - нейросети покруче. Один лимит дешевле зоопарка отдельных подписок - всего 900 рублей в месяц. Оплата картой РФ или СБП, работает без VPN. Первые задачи бесплатно, просто зарегистрируйся и попробуй. Делегируй рутину уже сегодня: catcode.dev

😍 PostgreSQL Zero to Hero — большой русскоязычный материал по изучению PostgreSQL! Здесь разобраны основы SQL, проектирование баз данных, индексы, транзакции, MVCC, WAL, оптимизация запросов, репликация, бэкапы и многое другое. Подойдёт разработчикам, которые хотят системно изучить PostgreSQL и разобраться не только с SQL, но и с архитектурой, производительностью, эксплуатацией базы данных.

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

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

📂 Шпаргалка по структурам данных! Например, стек работает по принципу LIFO — последний добавленный элемент извлекается первым, а очередь наоборот использует FIFO — первым выходит тот, кто пришёл первым. На картинке — 7 основных структур данных: массивы, связные списки, стек, очередь, хеш-таблица, дерево и граф. Полезная база, которую стоит знать каждому разработчику. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

❤️ SQL-шпаргалка — основные конструкции и приёмы работы с базами данных! Справочник по SQL с примерами запросов и пояснениями. Здесь на небольших таблицах разобраны INNER, LEFT, RIGHT, FULL и CROSS JOIN, а также показаны различия синтаксиса между PostgreSQL, MySQL, SQLite и SQL Server. Для команд указано, что именно они делают и в каких ситуациях применяются. 📌 Оставляю ссылочку: tools.sitebyme.ru ➡️ SQL Ready | #ресурс

Проверяйте преобразование без исключений! Обычный cast падает с ошибкой, если значение нельзя преобразовать. Из-за этого в ETL и в запросах к промежуточным данным часто приходится заранее чистить данные или писать PL/pgSQL с обработкой исключений.

SELECT value::integer
FROM staging;
-- ERROR при первом плохом значении

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

SELECT value
FROM staging
WHERE pg_input_is_valid(value, 'integer');

Типом может быть не только integer:

SELECT pg_input_is_valid('192.168.1.10', 'inet');
SELECT pg_input_is_valid('550e8400-e29b-41d4-a716-446655440000', 'uuid');
SELECT pg_input_is_valid('2026-09-08', 'date');

А pg_input_error_info() позволяет получить причину, почему преобразование невозможно.

SELECT *
FROM pg_input_error_info('2026-02-30', 'date');

🔥 pg_input_is_valid() позволяет валидировать грязные входные данные средствами самой системы типов PostgreSQL. ➡️ SQL Ready | #совет

7 дней бесплатного обучения во Frontend-разработке! 🔥 Ухвати свой шанс погрузиться в мир Frontend-разработки на нашем бесплатном онлайн-интенсиве! Интересные уроки, практическая работа и поддержка куратора — всё это доступно тебе прямо сейчас. Всего за 7 дней ты: 1. Сгенерируешь сайт через Giga, DeepSeek, ChatGPT; 2. Сверстаешь весь сайт на HTML + CSS с правильным адаптивом; 3. Оживишь проект на JavaScript: логика, расчёты и трекинг заказов; 4. Подключишь карты и API, увидишь, как данные работают в настоящем продукте; 5. Получишь экспертные советы, как улучшить свои проекты и вывести их на профессиональный уровень. В итоге добавишь в своё портфолио уникальный проект сервиса доставки, доступный по ссылке, который повысит твою ценность как специалиста. 🔥 С нас обучение, практика и поддержка на пути к фрилансу. С тебя участие в интенсиве 👉 Начать бесплатное обучение Не упусти шанс получить мощный заряд уверенности для дальнейшего роста в разработке!

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

😎 PostgreSQL FAQ — справочник по частым проблемам и вопросам! Здесь собраны разборы типичных ситуаций при работе с PostgreSQL: проблемы с подключением и настройкой, ошибки в SQL, оптимизация медленных запросов, партиционирование, размеры таблиц, timestamp with time zone, pg_dump и другие нюансы. Есть конкретные команды, примеры диагностики и рекомендации по тому, какие данные собирать для поиска проблем.

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

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

Настройки только для одного запроса! Необязательно менять statement_timeout, work_mem или другие параметры для всей сессии. SET LOCAL действует только до конца текущей транзакции.

BEGIN;

SET LOCAL lock_timeout = '500ms';

ALTER TABLE orders
ADD COLUMN source text;

COMMIT;

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

BEGIN;

SET LOCAL work_mem = '512MB';

SELECT customer_id, count(*)
FROM events
GROUP BY customer_id;

COMMIT;

Можно даже точечно дать тяжёлому запросу больше памяти, не увеличивая work_mem для остальных запросов соединения. 🔥 SET LOCAL позволяет тюнить PostgreSQL под конкретную операцию и автоматически возвращает настройки назад после COMMIT или ROLLBACK. ➡️ SQL Ready | #совет

Коротко и по работному делу! — Море IT & Digital вакансий на удалёнку — Каждый день — Прямые контакты HR Подписаться на канал 🤘

✍️ Попалась интересная статья на Хабре: «Почему в БД на PostgreSQL популярен тип numeric?»! В этой статье: • Разберётесь, почему для денег и точных расчётов часто выбирают numeric, несмотря на его производительность; • Узнаете, чем на практике отличаются numeric, целые типы и double precision; • Посмотрите, какие требования к точности и округлению предъявляют SQL, платёжные системы и финансовые стандарты.

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

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

Почему OFFSET деградирует на больших таблицах! OFFSET часто используют для пагинации, потому что запрос выглядит просто. На небольших таблицах проблем обычно нет, но на больших объёмах стоимость такого подхода растёт вместе с глубиной страницы. Есть таблица:

events(
    id BIGINT,
    user_id BIGINT,
    payload JSONB,
    created_at TIMESTAMPTZ
)

Типичная пагинация:

SELECT
    id,
    user_id,
    created_at
FROM events
ORDER BY created_at DESC
LIMIT 50 OFFSET 1000000;

Кажется, что база должна просто пропустить миллион строк и вернуть следующие 50. Но SQL-движок не может сделать настоящий прыжок через OFFSET. Ему нужно обработать строки до нужной позиции, а потом отбросить их. Без подходящего индекса это может выглядеть так: база читает строки, определяет порядок сортировки, обрабатывает OFFSET + LIMIT записей, выбрасывает ненужные строки и возвращает только нужный результат. Даже если есть индекс:

CREATE INDEX idx_events_created_at
ON events(created_at DESC);

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

LIMIT 50 OFFSET 1000000;

означает, что базе нужно обработать примерно миллион строк перед тем, как вернуть результат. Для глубоких страниц обычно используют keyset pagination (cursor pagination). Вместо номера страницы передаётся последнее значение из предыдущего результата:

SELECT
    id,
    user_id,
    created_at
FROM events
WHERE created_at < '2026-08-01 12:00:00'
ORDER BY created_at DESC
LIMIT 50;

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

2026-08-01 12:00:00

2026-08-01 12:00:00

2026-08-01 12:00:00

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

CREATE INDEX idx_events_cursor
ON events(created_at DESC, id DESC);

И запрос становится:

SELECT
    id,
    user_id,
    created_at
FROM events
WHERE (created_at, id) < ('2026-08-01 12:00:00', 1500000)
ORDER BY created_at DESC, id DESC
LIMIT 50;

Теперь курсор точно определяет позицию в индексе. Главное преимущество такого подхода — стоимость запроса зависит в основном от размера страницы, а не от глубины пагинации. Первая страница:

LIMIT 50;

и страница после миллионов записей:

WHERE (created_at, id) < (...)
LIMIT 50;

используют один и тот же принцип: найти позицию в B-tree индексе и продолжить чтение. OFFSET остаётся нормальным решением для административных интерфейсов, внутренних инструментов и небольших таблиц. Но для лент событий, истории операций, логов и больших списков он быстро становится узким местом. 🔥 Делаем вывод: OFFSET удобен для разработки, но плохо масштабируется на больших объёмах данных. Для больших таблиц лучше использовать keyset pagination с составным индексом и стабильным курсором. ➡️ SQL Ready | #практика

Сколько вакансий ты упускаешь, пока ищешь работу? 👀 Они разбросаны по десяткам Telegram-каналов, hh ru, карьерным сайтам и другим площадкам. Пока ты мониторишь одни источники, подходящая вакансия может появиться в другом. Софи забирает этот поиск на себя. Она ищет подходящие вакансии в 350+ Telegram-каналах, на hh ru, карьерных сайтах компаний, Geekjob и youngjunior.ru Сама изучает вакансии, пишет персональные сопроводительные и отправляет отклики. Тебе больше не нужно каждый день выбирать, где искать работу и на что откликаться. Софи будет искать везде. Доступ откроется 22 сентября. Первые 3 дня - бесплатно. Мест немного. Подпишись, чтобы не пропустить старт.

📂 Шпаргалка по снижению Latency в Backend-системах! Например, Cache позволяет отдавать часто используемые данные без обращения к базе данных, а Load Balancer распределяет запросы между несколькими серверами, повышая скорость и отказоустойчивость приложения. На картинке — основные стратегии уменьшения задержек в высоконагруженных системах. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

😍 zasqlpython — платформа для изучения и практики SQL! Сайт позволяет изучать SQL с нуля и сразу закреплять материал на практике. Бесплатный курс включает 10 уроков и 92 задачи с автоматической проверкой прямо в браузере. После базового курса можно перейти к SQL-тренажёру с сотнями задач повышенной сложности и заданиями в формате собеседований. 📌 Оставляю ссылочку: zasqlpython.ru ➡️ SQL Ready | #ресурс