SQL Ready | Базы Данных

📂 Напоминалка по 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 🤫

📂 Напоминалка как выполняется SQL-запрос в реляционной СУБД! Например, Transport Subsystem — приём запроса от клиента по сетевому протоколу, установка сессии, а Query Processor — синтаксический и семантический разбор, построение дерева запроса (parse tree). На схеме показан полный путь запроса — от клиента до хранения данных. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

Индекс для поиска по шаблону, который действительно работает! Обычные B-tree индексы хорошо работают только для шаблонов вида prefix%. Но при поиске по подстроке (%text%) или сложных шаблонах они обычно не используются, и запрос превращается в полный скан таблицы даже на миллионах строк.

CREATE EXTENSION IF NOT EXISTS pg_trgm;

Расширение pg_trgm добавляет триграммные индексы, которые эффективно ищут подстроки, частичные совпадения и нечёткие шаблоны:

CREATE INDEX users_email_trgm_idx
ON users USING gin (email gin_trgm_ops);

После этого запросы вроде:

SELECT *
FROM users
WHERE email ILIKE '%company%';

Начинают использовать индекс и ускоряются, особенно для поиска по почте, логинам, URL и другим текстовым идентификаторам:

EXPLAIN ANALYZE
SELECT *
FROM users
WHERE email ILIKE '%company%';

🔥 Важно: триграммный индекс занимает больше места и замедляет INSERT/UPDATE, но для больших таблиц с поиском по подстроке это почти всегда оправдано. ➡️ SQL Ready | #совет

Импортозамещение СУБД: как не прогадать и выбрать подходящую отечественную платформу? При миграции на российскую СУБД очень важно выбрать решение, которое не просто соответствует определенным характеристикам, а действительно впишется в вашу инфраструктуру и обеспечит стабильность в долгосрочной перспективе. Эксперты К2Тех приняли участие в исследовании отечественных СУБД, организованном аналитическим порталом «ИТ-инфраструктура». На портале вы найдете таблицы сравнения решений по 30+ критически важным параметрам, в том числе: • Надежность и High Availability • Производительность • Управление и мониторинг • Эксплуатация Таблицы позволят сопоставить решения по архитектурным и эксплуатационным характеристикам и станут основой для технической оценки перед пилотом. 🔗 Получите доступ к материалам портала «ИТ-инфраструктура» для первичного анализа решений по ссылке

☕️ Introduction to SQL — открытая книга по SQL, краткое и практичное руководство! Это полноценный бесплатный ресурс в формате репозитория, который даёт основу работы с реляционными базами данных. Здесь структура БД, таблицы, SELECT, JOIN, подзапросы, агрегаты, изменение данных и экспорт баз. Материал ориентирован на реальные задачи DevOps, backend-разработки и системного администрирования.

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

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

Постоянные представления, как слой архитектуры! VIEW — сохранённый запрос, как объект схемы. Для обычных VIEW данные не дублируются: оптимизатор, как правило, раскрывает их в подзапрос и строит единый план (зависит от СУБД):

SELECT *
FROM active_users
WHERE email LIKE '%@company.com';

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

CREATE OR REPLACE VIEW active_users AS
SELECT id, name, email
FROM users
WHERE deleted_at IS NULL
  AND NOT is_blocked;

CREATE OR REPLACE позволяет централизованно менять логику (если сохраняется совместимый контракт колонок), не переписывая клиентские запросы:

GRANT SELECT ON active_users TO reporting_role;

🔥 Права можно выдавать на VIEW, а не на таблицу, скрывая лишние поля и фиксируя допустимую проекцию (механика зависит от СУБД). ➡️ SQL Ready | #совет