👨‍💻 Yandex Cloud — инженерные материалы по SQL и базам данных!

На сайте собраны статьи и документация по работе с базами данных и SQL. Материалы помогают разобраться не только с написанием запросов, но и с тем, как работают внутренние механизмы СУБД: транзакции, индексы, оптимизация запросов, распределённые базы данных и эксплуатация систем.

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

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

📂 Git Fundamentals: шпаргалка по основным операциям и workflow!

Разобраны основные элементы Git-экосистемы: структура репозитория, работа с индексом (staging area), создание коммитов, управление ветками, слияние изменений, взаимодействие с remote-репозиториями и основные команды для ежедневной разработки.

На картинке — визуальное представление Git workflow, жизненный цикл изменений от рабочей директории до удалённого репозитория, а также базовые операции commit, branch, merge, fetch, pull и push.

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

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

🧐 Материалы по базам данных — информатвный набор для изучения SQL и СУБД!

Большая подборка учебных материалов по базам данных: книги, лекции, лабораторные работы и задания по SQL, PostgreSQL и Microsoft SQL Server. Внутри собраны материалы по ключевым темам, которые нужны разработчику при работе с базами данных: основы реляционной модели и проектирования БД, нормализация данных и ограничения (constraints), агрегатные функции, JOIN, подзапросы и др.

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

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

Сравнивайте несколько колонок как одно значение!

В PostgreSQL необязательно расписывать сравнение нескольких полей через длинные цепочки AND и OR. Можно использовать row constructor comparison — сравнить сразу кортежи значений.

Например, условие для keyset pagination часто пишут так:

WHERE user_id > :user_id
   OR (user_id = :user_id AND id > :id)

Но PostgreSQL умеет выразить то же самое напрямую:

WHERE (user_id, id) > (:user_id, :id)
ORDER BY user_id, id
LIMIT 100;

Сравнение идёт слева направо: сначала user_id, а если значения равны — id. Поэтому конструкция естественно совпадает с лексикографическим порядком составного ORDER BY.

И это не просто сокращение синтаксиса. Под такой запрос можно сделать обычный составной B-tree индекс:

CREATE INDEX orders_user_id_id_idx
ON orders (user_id, id);

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

WHERE (year, month) >= (2026, 4)
  AND (year, month) <  (2027, 1)

🔥 Row comparison позволяет заменить громоздкую булеву логику сравнением кортежей и особенно хорошо ложится на keyset pagination и составные B-tree индексы. Важно только помнить про NULL: обычные сравнения с ним могут дать UNKNOWN.

➡️ SQL Ready | #совет

👨‍💻 Наткнулся на интересную статью на Хабре: «Реализация автоудаления блокирующих сессий в MS SQL»!

В этой статье:
• Разбирается механизм поиска корневых блокирующих сессий с помощью системных представлений MS SQL Server;
• Показывается, как реализовать автокиллер на T-SQL с логированием, анализом цепочек блокировок и безопасным удалением зависших транзакций;
• Объясняется, как автоматизировать мониторинг блокировок через SQL Server Agent и сохранить историю для последующего анализа.

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

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

📂 Напоминалка по возможностям PostgreSQL!

Например, PostgreSQL отлично подходит не только для обычных CRUD-приложений (OLTP), но и для аналитики (OLAP), работы с геоданными, временными рядами, распределёнными таблицами и интеграции с внешними источниками данных через Foreign Data Wrapper (FDW).

На картинке — обзор основных направлений применения PostgreSQL и популярных расширений.

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

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

🧐 Шпаргалка по оконным функциям SQL с примерами!

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

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

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

📂 Напоминалка по проектированию систем (System Design)!

Например, Load Balancing распределяет нагрузку между сервисами, Caching ускоряет доступ к данным, а Replication и Sharding помогают масштабировать базы данных.

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

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

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

🧐 Крутая статья лежит на Хабре: «Avalon: как построить эффективный Feature Store на YDB»!

В этой статье:
• Разбирается архитектура Avalon — масштабируемого Feature Store для централизованного хранения и быстрого получения миллиардов признаков;
• Показывается, как с помощью YDB организованы шардирование, точечные и batch-запросы, импорт данных, ACL и Change Data Capture;
• Рассказывается, какие архитектурные решения позволяют системе работать с 6,5 млрд ключей и выдерживать до 100 тысяч RPS на чтение при P95 около 5 мс.


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

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

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

Например, SEMI JOIN позволяет получить строки, для которых есть совпадение в другой таблице, ANTI JOIN — найти строки без совпадений, а NATURAL JOIN автоматически соединяет таблицы по одноимённым столбцам.

На картинке — наглядное сравнение трёх подходов: SEMI JOIN через EXISTS, ANTI JOIN через NOT EXISTS и NATURAL JOIN, а также показано, чем SEMI JOIN отличается от обычного INNER JOIN.

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

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

Временные таблицы: различия между TEMP, CTE и материализацией данных!

В SQL существует несколько способов работать с промежуточными результатами. Основные варианты — временные таблицы, CTE через WITH и обычные подзапросы. Выбор между ними влияет на читаемость запроса, возможность повторного использования данных и работу оптимизатора.

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

CREATE TEMP TABLE monthly_sales AS
SELECT
    customer_id,
    SUM(amount) AS total_amount
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY customer_id;

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

SELECT *
FROM monthly_sales
WHERE total_amount > 10000;

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

CREATE INDEX idx_monthly_sales_customer_id
ON monthly_sales(customer_id);

CTE (Common Table Expression) создаётся с помощью конструкции WITH и существует только во время выполнения одного SQL-запроса. Он помогает сделать сложную логику более читаемой и структурированной.

WITH monthly_sales AS (
    SELECT
        customer_id,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY customer_id
)
SELECT *
FROM monthly_sales
WHERE total_amount > 10000;

В PostgreSQL начиная с версии 12 CTE может быть автоматически встроен оптимизатором в основной запрос. Это называется CTE inlining. В таком случае отдельное промежуточное хранилище данных не создаётся.

WITH active_users AS MATERIALIZED (
    SELECT *
    FROM users
    WHERE status = 'active'
)
SELECT *
FROM active_users;

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

WITH user_stats AS MATERIALIZED (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
)
SELECT
    a.user_id,
    a.orders_count
FROM user_stats a
JOIN user_stats b
    ON a.user_id = b.user_id;

Однако использование CTE не всегда означает материализацию. PostgreSQL самостоятельно выбирает оптимальный способ выполнения запроса, если не указано MATERIALIZED или NOT MATERIALIZED.

WITH user_stats AS NOT MATERIALIZED (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
)
SELECT *
FROM user_stats;

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

CREATE TEMP TABLE user_stats AS
SELECT
    user_id,
    COUNT(*) AS orders_count
FROM orders
GROUP BY user_id;

CREATE INDEX idx_user_stats_user_id
ON user_stats(user_id);

ANALYZE user_stats;

Команда ANALYZE после заполнения временной таблицы помогает PostgreSQL получить актуальную статистику и выбрать более эффективный план выполнения запроса.

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

SELECT *
FROM (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
) s
WHERE orders_count > 50;

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

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

👨‍💻 Koddo — сайт с теорией и практикой для обучения!

Платформа для изучения SQL через решение реальных задач прямо в браузере. На практике разбираются выборки и фильтрация, GROUP BY и HAVING, JOIN, работа с датами, подзапросы, CTE и оконные функции. Решения автоматически проверяются, а AI-ассистент может дать подсказку, не раскрывая готовый ответ.

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

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

Работайте с периодами как с одним значением!

Когда у записи есть start_at и end_at, проверки пересечений быстро превращаются в набор сравнений. В PostgreSQL для этого есть range types: например, tstzrange для диапазона timestamptz.

Вместо:

WHERE start_at < :end_at
  AND end_at > :start_at

можно явно работать с диапазонами:

WHERE tstzrange(start_at, end_at, '[)')
   && tstzrange(:start_at, :end_at, '[)')

Оператор && означает «диапазоны пересекаются». [) задаёт полуинтервал: начало включено, конец исключён, поэтому встреча до 12:00 и следующая с 12:00 не считаются пересекающимися.

Но интереснее то, что PostgreSQL умеет проверять диапазоны и другими операторами:

period @> now()       -- содержит момент времени
period && :period     -- пересекается
period <@ :period     -- находится внутри

Если такие проверки выполняются постоянно, диапазон можно хранить непосредственно в таблице и индексировать GiST:

CREATE INDEX bookings_period_idx
ON bookings USING gist (period);

И самое полезное: правило «для одной комнаты интервалы не должны пересекаться» можно перенести из приложения непосредственно в БД:

CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE bookings
ADD CONSTRAINT bookings_no_overlap
EXCLUDE USING gist (
    room_id WITH =,
    period  WITH &&
);

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

🔥 Range types превращают интервалы времени из пары колонок и ручной логики в полноценный тип данных: его можно сравнивать, индексировать и даже запретить пересечения на уровне констрейнта.

➡️ SQL Ready | #совет