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

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

На картинке — основные операторы SQL, типы JOIN’ов и правильный порядок выполнения запроса внутри СУБД.

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

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

✍️ Bilabon — задачи и теория по MySQL!

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

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

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

SYSDATE в условиях — почему = SYSDATE почти никогда не то, что нужно!

В Oracle SYSDATE возвращает текущие дату и время с точностью до секунды. Частая ошибка — пытаться выбрать записи «за сегодня» через прямое сравнение.

Представим таблицу:

orders(id, created_at DATE)

Интуитивный вариант:

SELECT *
FROM orders
WHERE created_at = SYSDATE;

Логически кажется правильным — взять записи за текущий день. Но условие почти никогда не выполнится.

Тип DATE в Oracle хранит и дату, и время (до секунды). Чтобы совпадение произошло, created_at должен быть ровно равен текущему моменту до секунды. На практике такой запрос почти всегда возвращает пустой результат.

Попытка исправить через TRUNC:

SELECT *
FROM orders
WHERE TRUNC(created_at) = TRUNC(SYSDATE);

Работает корректно, но есть нюанс — функция применяется к колонке, поэтому обычный индекс по created_at не используется (если только нет function-based index на TRUNC(created_at)).

Правильный способ — диапазон по дате:

SELECT *
FROM orders
WHERE created_at >= TRUNC(SYSDATE)
  AND created_at <  TRUNC(SYSDATE) + 1;

Такое условие индекс-дружелюбное (sargable), и оптимизатор может использовать индекс. Запрос выбирает все записи за текущие сутки независимо от времени (по часовому поясу сессии/сервера БД).

Аналогично можно искать за любой день:

WHERE created_at >= DATE '2026-02-18'
  AND created_at <  DATE '2026-02-19'

Поскольку DATE хранит время, прямое равенство по дате почти никогда не подходит для выборки «за день».

🔥 Для выборки за день используйте полуоткрытый диапазон, а не сравнение с SYSDATE.

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

Проверка совпадений сразу по нескольким полям одной операцией!

Когда нужно сравнить строки по составному ключу, многие пишут условия с AND, которые хуже читаются и сложнее поддерживаются:

u.email = b.email AND u.phone = b.phone

SQL умеет сравнивать кортежи целиком (row value), поэтому несколько колонок можно проверить одним выражением:

(email, phone)

Поддержка зависит от СУБД. Учитывайте поведение NULL и наличие составных индексов, оптимизация не всегда идентична AND.

🔥 Это особенно полезно при фильтрации, дедупликации, проверке попадания в списки, синхронизации таблиц и миграциях данных.

➡️ SQL Ready | #совет

Дедупликация с приоритетом, оставляем лучшую строку!

Когда есть дубликаты по ключу (например, email), нужно сохранить запись с максимальным приоритетом — подтверждённую или самую новую.

Таблица: users(id, email, is_verified, created_at)

Сначала можно увидеть, какая строка будет считаться главной. Нумеруем строки внутри каждого email по приоритету:

SELECT id, email,
       ROW_NUMBER() OVER (
         PARTITION BY email
         ORDER BY is_verified DESC, created_at DESC
       ) rn
FROM users;

Оконная функция делит строки по email и присваивает номер согласно приоритету, где подтверждённые и более новые записи идут первыми.

Оставим только одну запись на email — ту, у которой rn = 1:

SELECT *
FROM (
  SELECT *,
         ROW_NUMBER() OVER (
           PARTITION BY email
           ORDER BY is_verified DESC, created_at DESC
         ) rn
  FROM users
) t
WHERE rn = 1;

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

В PostgreSQL можно сделать то же самое короче:

SELECT DISTINCT ON (email)
       id, email, is_verified, created_at
FROM users
ORDER BY email, is_verified DESC, created_at DESC;

Здесь ORDER BY фактически задаёт правило выбора победителя внутри каждой группы. СУБД оставит одну строку на email согласно приоритету сортировки.

🔥 Такой приём используют при очистке импортов, объединении источников данных и выборе канонической записи пользователя.

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

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

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

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

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

👨👨👨👨👨👨👨👨👨👨

Каналы с Junior IT вакансиями
и стажировками

Подписывайся и забирай свой оффер 🤘

1. Стажировки и вакансии по России и миру
2. IT вакансии по СНГ
3. IT стажировки по СНГ
4. ИИ-ассистент для автооткликов
5. IT стажировки и волонтерства
6. IT стажировки в топовых компаниях мира
7. Удалённые IT вакансии и стажировки
8. Python вакансии и стажировки
9. БИГТЕХ вакансии и стажировки
10. Design вакансии и стажировки
11. QA вакансии и стажировки
12. Junior вакансии и стажировки
13. Frontend вакансии и вопросы собесов
14. Вакансии и стажировки для аналитиков
15. Вакансии в русских стартапах за границей
16. Вакансии и стажировки для DevOps
17. Вакансии, которых нет на ХХ.РУ

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

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

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

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

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