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 | #практика

👩‍💻 Хватит учить только синтаксис, начинай делать реальные проекты! Python Ready — авторский канал, где Python перестаёт быть только теорией и становится рабочим инструментом. Мини-проекты, боты, советы, разборы задач, гайды и шпаргалки для каждого программиста. 🔥 Советую подписаться: @python_ready

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

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

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

🖥 Объединяем пересекающиеся интервалы автоматически! В реальных данных интервалы часто перекрываются или соприкасаются, из-за чего сложно понять фактические периоды непрерывной активности или занятости. Сегодня в задаче:

• Определим, насколько далеко тянется текущая занятость, отслеживая максимальный конец интервалов; • Найдём точки разрыва, где начинается новый независимый блок времени; • Объединим пересечения в итоговые непрерывные диапазоны.

Этот приём используют для анализа сессий, расписаний, бронирований и любых временных событий, где важно видеть реальные интервалы. ➡️ SQL Ready | #задача

Собрал чат-бота за вечер → заработал 9 000₽. Так и работают специалисты по чат-ботам: открыл шаблон → собрал бота как конструктор → получил деньги. Инструкция по сборке тут: 👉 @other_digital_bot

📂 Напоминалка по SQL — базовые команды и порядок выполнения запроса! Например, SELECT отвечает за выборку данных, FROM — за указание источника (таблицы), а WHERE позволяет отфильтровать строки по условию. На картинке — основные операторы SQL, типы JOIN’ов и правильный порядок выполнения запроса внутри СУБД. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

Вычисление временных интервалов между датами! PostgreSQL умеет возвращать полноценный интервал одной операцией:

now() - created_at

Если нужно получить возраст записи в читаемом виде (годы-месяцы-дни), есть функция age(), которая учитывает календарь, а не просто секунды:

SELECT age(now(), created_at)
FROM orders;

А когда требуется число дней или часов для аналитики, интервал можно сразу привести к нужной единице:

EXTRACT(EPOCH FROM now() - created_at) / 3600

🔥 Полезно для TTL-логики, SLA-метрик, мониторинга задержек и любых задач, где время жизни записи, является ключевым параметром. ➡️ SQL Ready | #совет

👩‍💻 В сеть вывалилась гигантская куча курсов и книг от топовых IT‑школ Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё! • 1612 ГБ — DevOps • 1402 ГБ — Python • 1300 ГБ — C, C++ • 1815 ГБ — Frontend • 1515 ГБ — Backend • 898 ГБ — ИБ, Хакинг • 996 ГБ — Kotlin, Swift • 212 ГБ — JavaScript • 315 ГБ — Flutter • 820 ГБ — Go, PHP • 419 ГБ — Java, Rust • 648 ГБ — GameDev • 517 ГБ — Windows, Linux • 998 ГБ — Дизайн (UX/UI) • 617 ГБ — Нейросети (ML/RL) • 546 ГБ — БД (SQL & NoSQL) • 687 ГБ — Аналитика данных • 115 ГБ — QA-тестирование Подписывайся и не плати за то, что можно получить бесплатно

💡 SQL Fiddle — онлайн платформа для тестирования SQL без установки БД! Сервис позволяет писать, запускать и проверять SQL-запросы прямо в браузере. Можно создать схему базы, заполнить тестовыми данными и сразу увидеть результат выполнения, идеально для экспериментов, обучения и разбора задач. Поддерживает разные СУБД (MySQL, PostgreSQL, Oracle, SQL Server и др.), поэтому удобно сравнивать поведение запросов. 📌 Оставляю ссылочку: sqlfiddle.com ➡️ SQL Ready | #сайт

FlowchartAI — это бесплатный AI-генератор блок-схем, который из текста или кода автоматически строит диаграмму. Он анализирует твой ввод (описание процесса/алгоритма или код) и превращает его в визуальную блок-схему, которую можно смотреть прямо в браузере без регистрации. 📌 Оставляю ссылочку: flowchartai.org ➡️ SQL Ready | #ресурс

TRUNC(date) — как правильно обрезать дату в Oracle без потери индекса! В Oracle тип DATE хранит дату и время одновременно. Частая задача — сравнить только по дате, игнорируя время. Многие используют TRUNC(date), но это может сильно ухудшить производительность. Представим таблицу:

orders(id, created_at DATE)

Нужно выбрать заказы за 18 февраля 2026. Интуитивный вариант:

SELECT *
FROM orders
WHERE TRUNC(created_at) = DATE '2026-02-18';

Логически верно, но есть проблема. Функция применяется к колонке — поэтому обычный индекс по created_at в основном не используется, и Oracle вынужден вычислять TRUNC для множества строк, что часто приводит к полному сканированию. Правильный способ — диапазон по дате:

SELECT *
FROM orders
WHERE created_at >= DATE '2026-02-18'
  AND created_at <  DATE '2026-02-19';

Теперь условие индекс-дружелюбное (sargable) — оптимизатор может использовать обычный индекс по created_at. Этот подход корректно работает независимо от времени в поле. TRUNC(date) полезен в SELECT или GROUP BY, когда фильтрация по индексу не критична:

SELECT
    TRUNC(created_at) AS day,
    COUNT(*) AS orders_count
FROM orders
GROUP BY TRUNC(created_at)
ORDER BY day;

Если всё же нужно часто фильтровать по TRUNC(created_at), можно создать функциональный индекс:

CREATE INDEX idx_orders_created_day
ON orders (TRUNC(created_at));

После этого запрос с TRUNC сможет использовать индекс. Функция TRUNC умеет обрезать дату до разных уровней:

SELECT
    TRUNC(SYSDATE)         AS day,
    TRUNC(SYSDATE, 'MM')   AS month_start,
    TRUNC(SYSDATE, 'YYYY') AS year_start
FROM dual;

Поддерживаются форматы: DD (день), MM (месяц), YYYY (год), IW (ISO-неделя) и др. DATE хранит дату со временем, поэтому = DATE '2026-02-18' не находит все записи за день; функции над колонками мешают индексам. 🔥 Для фильтрации по дате используйте диапазоны, а TRUNC — для отображения, агрегации или вместе с функциональным индексом. ➡️ SQL Ready | #практика

🔥 Пожизненная PRO-подписка на easyoffer по цене одного года. Беспрецедентная акция на PRO-тариф сайта для подготовки к собеседованию на программиста, тестировщика, проектного менеджера и другие IT-профессии. ⚙️ Доступные функции сейчас: 1. База вопросов из реальных технических собеседований с вероятностью встречи и примерами ответов. 2. База задач с этапа live-coding. 3. База 1100+ реальных собеседований, в том числе в топовые компании (Сбер, Авито, Яндекс, WB, OZON, МТС и др.) на позиции Junior/Middle/Senior. 4. База 400+ тестовых заданий от компаний. 5. Аналитика ТОП-требований из вакансий для лучшего написания резюме по ключевым словам. 6. Тренажеры для подготовки к собеседованию. В том числе тренажер «Реальное собеседование» со сценарием вопросов под конкретную компанию. ⌛️ Функции, которые появятся в ближайшие полгода: 1. Агрегатор вакансий из Telegram, сайтов компаний и джоббордов. 2. Улучшение и оптимизация резюме, чтобы проходить ATS-системы. 3. Генерация уникального резюме и сопроводительного письма под вакансию. Акция до 20 февраля (включительно) на PRO-тариф. Покупаешь сейчас один раз — пользуешься всю жизнь без лимита, включая все будущие функции. 👉 Смотри подробности тарифа и покупай на easyoffer

💡 Отличную статью нашёл на Хабре: «Демобаза 2.0 для PostgreSQL»! В этой статье: • Показано, как устроена учебная база, приближенная к реальным продакшен-сценариям с миллионами записей; • Разобрано, как генерируются правдоподобные данные через имитацию работы системы, включая бронирования и жизненный цикл событий; • Объясняется, какие задачи по SQL, аналитике и производительности можно отрабатывать на такой базе.

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

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

Проверка наличия связанных данных! Когда нужно проверить существование связанных строк, обычный JOIN часто увеличивает результат или заставляет делать DISTINCT, что бьёт по производительности:

SELECT *
FROM orders o
WHERE EXISTS (
  SELECT 1 FROM payments p
  WHERE p.order_id = o.id
);

EXISTS останавливается на первой найденной строке и не создаёт дубликатов, поэтому обычно работает быстрее и предсказуемее:

SELECT *
FROM orders o
WHERE NOT EXISTS (
  SELECT 1 FROM payments p
  WHERE p.order_id = o.id
);

NOT EXISTS - наиболее корректный способ найти записи без соответствующих связанных данных. В отличие от NOT IN он корректнее работает при наличии NULL:

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id
WHERE p.order_id IS NULL;

🔥 LEFT JOIN + IS NULL делает то же самое логически, но чаще требует больше работы оптимизатора и может уступать по производительности на больших объёмах. ➡️ SQL Ready | #совет

🏆 Пройди ЛЮБОЕ собеседование! Всё для подготовки к IT-собесам в одном месте: база вопросов, записи собесов, лайвкодинг с реальными задачами, ключевые слова для резюме, стажировки и тренажёр. Выбирай направление: 🖥 Frontend — @frontend_yeahub 👩‍💻 Python — @python_yeahub 👩‍💻 Java — @java_yeahub 👣 Golang — @golang_yeahub 👩‍💻 Node.js — @node_yeahub 👩‍💻 C# — @csharp_yeahub 👩‍💻 C/C++ — @cpp_yeahub 👩‍💻 Android — @android_yeahub 🖥 PHP — @php_yeahub 💻 DevOps — @devops_yeahub 👩‍💻 QA — @qa_yeahub 👨‍💻 Вакансии — @job_yeahub База обновляется еженедельно — всегда актуальные вопросы с последних собеседований, курсы и материалы. 📌 Подпишись и получи оффер уже в 2026!

👍 TutorialsPoint — сайт с теорий и практикой в одном месте! Удобный онлайн-редактор, где можно быстро проверить SQL-запросы без установки СУБД и настройки окружения. Встроенные примеры позволяют сразу попробовать SELECT, JOIN, агрегатные функции, подзапросы и другие конструкции на готовых таблицах. Подходит для обучения, практики, подготовки к собесам. Также можно использовать, как мини шпаргалку. 📌 Оставляю ссылочку: tutorialspoint.com ➡️ SQL Ready | #сайт

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

orders(id, customer_id, amount, created_at)

Хотим увидеть все заказы и одновременно понимать, сколько денег каждый клиент потратил в сумме. Первая мысль — посчитать через GROUP BY:

SELECT
    customer_id,
    SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id;

Да, сумму он посчитает. Но список заказов пропадёт — останется по одной строке на клиента. Если коротко: GROUP BY считает по группе, но детали внутри группы выбрасывает. Решение через оконную функцию:

SELECT
    id,
    customer_id,
    amount,
    SUM(amount) OVER (PARTITION BY customer_id) AS total_amount
FROM orders;

PARTITION BY customer_id разбивает строки на независимые окна по клиентам. SUM(...) OVER (...) считает сумму внутри каждого окна, но строки не схлопывает — каждая остаётся на месте. В результате каждая строка — отдельный заказ и total_amount — сумма всех заказов этого клиента. Фильтрация по агрегату без GROUP BY — например, нужно выбрать только заказы тех клиентов, у которых суммарный оборот больше 1000:

SELECT *
FROM (
    SELECT
        *,
        SUM(amount) OVER (PARTITION BY customer_id) AS total_amount
    FROM orders
) t
WHERE total_amount > 1000;

Обратите внимание: фильтрация происходит уже после вычисления оконной функции. Никаких GROUP BY, никаких дополнительных JOIN. Та же логика через JOIN (для сравнения):

SELECT o.*
FROM orders o
JOIN (
    SELECT customer_id, SUM(amount) AS total_amount
    FROM orders
    GROUP BY customer_id
) s ON s.customer_id = o.customer_id
WHERE s.total_amount > 1000;

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

SELECT
    id,
    customer_id,
    amount,
    SUM(amount) OVER (PARTITION BY customer_id) AS total_amount,
    COUNT(*)  OVER (PARTITION BY customer_id) AS orders_count
FROM orders;

Получаем и общую сумму, и количество заказов клиента — прямо в каждой строке. 🔥 Используйте оконные функции, когда нужно посчитать итог по группе, но не потерять сами строки. Это базовый приём аналитического SQL, который постоянно встречается в реальных задачах. ➡️ SQL Ready | #практика

Российский хакер Валерий Илларионов третий раз нашёл лазейку в ChatGPT 5 Айтишник за пару дней нашёл способ отключить GPT и настраивать её под любые задачи В своём блоге «Доктор GPT» он делится множеством других лазеек, которые всё ещё не пофиксили. • Как пользоваться Veo 3 и другими генераторами видео • Как генерировать фото в Midjourney • Отключение в Gemini, GPT и Perplexity Секретные промты и протоколы собраны здесь — @DoctorGPT 🤫