👨‍💻 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 | #совет

📂 SQL в одной шпаргалке!

Например, SELECT, WHERE и ORDER BY отвечают за выборку, фильтрацию и сортировку данных, JOIN связывает таблицы, а GROUP BY, агрегатные и оконные функции помогают анализировать результаты запросов.

На картинке — структурированная карта SQL: от базовых запросов и объединения таблиц до CTE, подзапросов, DDL/DML/DCL/TCL, транзакций и ограничений целостности данных.

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

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

👨‍💻 Junior Database — база вопросов и ответов по SQL и базам данных!

В репозитории собраны 27 тем, которые часто встречаются при изучении баз данных и подготовке к техническим собеседованиям: транзакции и ACID, нормализация и денормализация, первичные и внешние ключи, JOIN, GROUP BY и HAVING, индексы, миграции, хранимые процедуры и триггеры. Также затрагиваются оптимизация запросов, партицирование, репликация, шардинг и различия между SQL и NoSQL.

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

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

📂 Шпаргалка по нормализации баз данных в MySQL!

Например, 1NF требует атомарных значений, 2NF избавляет от частичных зависимостей, а 3NF — от транзитивных. Для более сложных схем пригодятся BCNF и 4NF.

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

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

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

❤️ Интересная статья на Хабре: «Что такое RAGFlow и с чем его едят»!

В этой статье:
• Разберётесь, как RAGFlow помогает LLM работать с внутренними документами и снижать количество галлюцинаций;
• Узнаете, чем RAGFlow отличается от классического RAG и как он обрабатывает PDF, таблицы, схемы и сканы;
• Посмотрите, как развернуть RAGFlow и использовать его для баз знаний, техподдержки и аналитики.


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

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

UNIQUE и NULL в PostgreSQL 15!

До PostgreSQL 15 уникальные ограничения считали NULL разными значениями. Это означало, что таблица спокойно принимала сколько угодно строк с NULL, даже если на колонке стоял UNIQUE.

CREATE TABLE users (
    email text UNIQUE
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Обе вставки выполнятся успешно.

Если NULL тоже должен быть уникальным, приходилось придумывать обходные пути. Кто-то делал частичные индексы, кто-то использовал COALESCE(), кто-то заводил отдельные флаги.

CREATE TABLE users (
    email text,
    CONSTRAINT users_email_key
        UNIQUE NULLS NOT DISTINCT (email)
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Вторая вставка уже завершится ошибкой. Для ограничения NULL считается таким же значением, как и любой другой ключ.

CREATE TABLE users (
    tenant_id int,
    email text,
    CONSTRAINT uq_user
        UNIQUE NULLS NOT DISTINCT (tenant_id, email)
);

Полезно, когда NULL — это полноценное значение предметной области, а не просто "неизвестно".

🔥 Небольшая возможность PostgreSQL 15, которая позволяет удалить сразу несколько старых костылей вокруг UNIQUE.

➡️ SQL Ready | #совет

🤔 SQL Lab — интерактивная платформа для изучения и практики SQL!

Сайт для тех, кто хочет освоить SQL через работу с запросами. Код пишется прямо в браузере: выполняете запрос, сразу видите результат и получаете автоматическую проверку решения. Обучение построено от базовых SELECT и ORDER BY до JOIN, подзапросов, транзакций, индексов, оптимизации запросов и PostgreSQL. Есть структурированные курсы с теорией и практикой.

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

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