❤️ Мега интересную статью нашёл на Хабре: «DOOMQL: DOOM-подобный многопользовательский шутер на чистом SQL»!

В этой статье:
• Показано, как реализовать полноценную игру, от хранения состояния до рендеринга 3D-сцены — средствами одной лишь базы данных;
• Разобрана архитектура, игровой цикл на транзакциях и многопользовательская синхронизация через SQL;
• На реальном проекте демонстрируются неожиданные возможности СУБД далеко за пределами типичных CRUD-задач.

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

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

📂 Напоминалка: как выполняется SQL-запрос в базе данных!

Например, когда отправляешь SELECT, UPDATE или другой SQL, СУБД сначала обрабатывает его внутренне, а уже потом выполняет.

На схеме — путь запроса: приём — разбор (парсер) — оптимизация — выполнение — доступ к данным — буферы, транзакции и блокировки — чтение/запись (память или диск).

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

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

Анти-JOIN — как корректно выбирать строки без связанных записей!

Частая задача в SQL — найти строки, для которых отсутствуют связанные записи в другой таблице. Это классический anti-join. Например, нужно получить клиентов, которые ни разу не сделали заказ.

Таблицы:

customers(id, name)
orders(id, customer_id, created_at)

LEFT JOIN + IS NULL:

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o  
  ON o.customer_id = c.id
WHERE o.id IS NULL;

LEFT JOIN возвращает всех клиентов. Если совпадений нет, поля из orders становятся NULL, и фильтр оставляет только клиентов без заказов.

Проверять нужно гарантированно NOT NULL колонку правой таблицы (обычно PK, например o.id), иначе возможны логические ошибки.

NOT EXISTS (предпочтительно):

SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
);

Запрос напрямую выражает отсутствие строк. В простом случае он эквивалентен LEFT JOIN, но лучше отражает намерение, устойчив к NULL в подзапросе и часто даёт более предсказуемый план при усложнении условий.

Почему не NOT IN:

SELECT c.id, c.name
FROM customers c
WHERE c.id NOT IN (
    SELECT customer_id
    FROM orders
);

Если подзапрос возвращает хотя бы один NULL, результат может стать пустым из-за трёхзначной логики SQL. Использовать этот вариант безопасно только при гарантированном NOT NULL в orders.customer_id.

Нюанс с условиями в JOIN:

SELECT c.id
FROM customers c
LEFT JOIN orders o  
  ON o.customer_id = c.id 
 AND o.created_at >= DATE '2026-01-01'
WHERE o.id IS NULL;

Этот запрос ищет клиентов без заказов после указанной даты.

Если требуется найти клиентов вообще без заказов, добавлять условия в JOIN нельзя — это меняет бизнес-смысл. В таком случае корректнее использовать NOT EXISTS.

🔥 Минимально необходим индекс orders(customer_id). При частой фильтрации по дате логичен составной индекс (customer_id, created_at).

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

❤️ Stepik SQL — практический курс с примерами запросов и упражнениями!

Этот репозиторий содержит структурированные задания, схемы баз данных и примеры SQL-запросов из курса на Stepik. Материалы охватывают работу с таблицами, фильтрацию, JOIN, группировки, агрегаты и другие ключевые темы языка, с акцентом на практику. Отличный ресурс для тех, кто хочет закрепить теорию через задачи.

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

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

Почему OFFSET может ломать производительность пагинации?

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

OFFSET 100000

Даже если вы не видите эти строки, СУБД всё равно читает их из индекса или таблицы, поэтому время выполнения растёт вместе с OFFSET:

SELECT *
FROM orders
WHERE id > :last_seen_id
ORDER BY id
LIMIT 10;

Эффективнее использовать keyset-pagination — продолжать выборку от последнего значения ключа, а не пропускать строки:

WHERE id > :last_seen_id

:last_seen_id — это id последней строки предыдущей страницы.

Такой запрос использует индекс напрямую (если id индексирован, обычно это PK), поэтому работает одинаково быстро на первой и на миллионной странице.

Если сортировка не уникальная (например created_at), добавляйте tie-breaker:

ORDER BY created_at, id
WHERE (created_at, id) > (:last_seen_created_at, :last_seen_id)

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

➡️ SQL Ready | #совет