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

Собрал чат-бота за вечер → заработал 9 000₽. Так и работают специалисты по чат-ботам: открыл шаблон → собрал бота как конструктор → получил деньги. Работы — на 2–3 часа. Оплата — 9–15 000₽ за сборку. Никакого программирования и долгих задач. Если умеешь открыть ворд или запустить косынку — справишься. А спрос сейчас бешеный: более 10 000 предпринимателей в месяц ищут тех, кто делает ботов и авторассылки. Это одна из самых простых и пустых ниш в онлайне — бери и зарабатывай. И главное: Собрать первого бота без опыта и получить клиента — проще, чем кажется. Все инструкции лежат здесь: 👉 @other_digital_bot Кто готов кликать мышкой и брать заказы — тот спокойно накопит на отдых, машину, квартиру и любые хотелки. Пробуй: @other_digital_bot

😎 Kaggle Learn — короткие практические модули с упражнениями и датасетами! Серия коротких и чётких микро-курсов с упором на практику: каждый модуль - это конкретная тема, упражнения и работа с настоящими датасетами прямо в браузере. Подходит для быстрого освоения основ языка, закрепления синтаксиса и понимания, как Python используется в реальных задачах. 📌 Оставляю ссылочку: kaggle.com ➡️ SQL Ready | #сайт

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

users(id, country, revenue)

Нужно разбить пользователей каждой страны на 4 группы по выручке — от меньшей к большей. Решение через NTILE:

SELECT
    id,
    country,
    revenue,
    NTILE(4) OVER (
        PARTITION BY country
        ORDER BY revenue
    ) AS revenue_quartile
FROM users;

NTILE(4) распределяет строки внутри каждой партиции на 4 группы максимально равного размера. ORDER BY определяет, какие значения попадут в «нижние» и «верхние» группы. Результат: quartile = 1 — пользователи с минимальной выручкой, quartile = 4 — пользователи с максимальной выручкой Важно: группы не всегда будут строго одинаковыми по размеру. Если строк не делится нацело, первые группы получат на одну строку больше. Если убрать PARTITION BY:

NTILE(4) OVER (ORDER BY revenue)

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

SELECT *
FROM (
    SELECT
        *,
        NTILE(10) OVER (
            PARTITION BY country
            ORDER BY revenue DESC
        ) AS decile
    FROM users
) t
WHERE decile = 1;

Так можно выбрать топ-10% пользователей в каждой стране. NTILE работает построчно и не агрегирует данные — каждая строка сохраняется, а группа добавляется как аналитическая метка. 🔥 Используйте NTILE, когда нужно сегментировать данные внутри группы на равные части без предварительной агрегации. ➡️ SQL Ready | #практика

Бесплатные нейронки, изменившие жизнь: 🤬 Обход GPT, Deepseek, Gemini, Sora - Читать гайд 🎁 Флирт бот, влюбит в тебя любую только он - Узнать название 💪 Помогает накачаться знает ВСЁ о питании - Узнать название 🎁 Решает домашку, по фотке твоего задания - Узнать название 💸 Генерир‌‎ует идеи для заработка, без бюджета - Узнать название 📉 Мониторит сайты и уведомляет о падении цен - Узнать название 📹 Делает тиктоки на сотни тысяч просмотров - Узнать название

👍 SQL Bootcamp — структурированная практика с упором на реальные задачи! Этот репозиторий построен как полноценный тренажёр: реальные схемы данных, последовательные задания и разборы запросов разной сложности. Помогает системно разобраться в работе с базами данных: выборки, сложные JOIN, агрегации, подзапросы, фильтрация, изменение данных и др.

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

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

🖥 Oracle: условная логика и выбор значений! Разбор типовых приёмов классификации данных, обработки NULL, подстановки значений по условиям и вычисления итоговых результатов прямо в запросах. Полезно для отчётов, аналитики, бизнес-логики в SELECT, упрощения WHERE и ORDER BY, а также для написания компактного и читаемого SQL без изменения схемы БД. ➡️ SQL Ready | #шпора

Пачку офферов заказывали? О всех трудоустройствах через ИИ-ассистента Софи ребята узнают от пользователей. И какой же кайф, когда они делятся своими историями. Вот так в чате узнали сразу о трех новых офферах: • Кейс Сергея - 2 недели в Софи и 2 оффера. • Кейс Елены - 1 неделя в Софи и оффер спустя 10 лет перерыва в работе. Елене 52 года. • Кейс Юлии - 1 месяц в Софи, свитчер из финансового аналитика в разработчика SQL. И еще один оффер🎉 Искренние поздравления ребятам и удачи им на новой работе! В следующий раз доступ в Софи откроется 24 февраля. Если хочешь получить 3 дня бесплатного доступа - подписывайся на этот канал, все анонсы будут там.

Одна таблица играет сразу несколько ролей? Иногда данные уже есть в одной таблице, но логически это разные сущности. Классический пример, иерархия: сотрудник и его менеджер хранятся в одной таблице employees:

FROM employees e
JOIN employees m

e — это сотрудник, m — это менеджер. Физически это одна и та же таблица, но логически, разные роли:

ON m.id = e.manager_id

Связь читается так, у сотрудника есть manager_id, который указывает на id другого сотрудника. 🔥 Такой приём используется не только для менеджеров. Категории и родительские категории, комментарии и ответы, версии сущностей, связи предыдущий / следующий, графы, цепочки состояний и др. ➡️ SQL Ready | #совет

🖥 Стажировки и вакансии для SQL разработчиков и администраторов. - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram 👉 @jobs_sql 🤖 ML & DS 👩‍💻 DevOps 👨‍✈️ ИБ & OSINT 👣 Go 👩‍💻 Mobile 👩‍💻 C# 👩‍💻 Node.js 👩‍💻 Python 🔎 QA 👩‍💻 Java 👩‍💻 UX/UI 👩‍💻 Frontend 🖼️ PHP 📋 Analyst 💼 1C 🖥 SQL 👩‍💻 IT HR Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

😎 На Хабре вышла полезнейшая статья про репликацию в 1С и реальные нагрузки на СУБД! В этой статье: • Разбирается, как вынести тяжёлые отчёты 1С с мастер-базы на реплику; • Показывается настройка репликации PostgreSQL/Tantor DB под реальные сценарии 1С; • Анализируются узкие места, задержки репликации и влияние отчётных запросов; • Даются результаты нагрузочного тестирования и выводы, которые можно применить в системах.

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

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

ORDER BY в подзапросах: почему порядок не гарантируется! ORDER BY управляет порядком строк только в финальном результате запроса. В подзапросах и CTE он не гарантирует порядок строк, если не используется вместе с ограничением количества возвращаемых данных. Причина в том, что оптимизатор может свободно менять план выполнения, пока итоговый результат формально остаётся корректным. Таблица событий:

events(id, user_id, created_at)

Попытка взять последние события через подзапрос:

SELECT *
FROM (
    SELECT *
    FROM events
    ORDER BY created_at DESC
) t;

Несмотря на явный ORDER BY внутри подзапроса, внешний запрос не содержит сортировки. Это означает, что порядок строк на выходе не определён, и СУБД имеет право проигнорировать внутреннюю сортировку как не влияющую на результат. Корректный вариант — сортировать во внешнем запросе:

SELECT *
FROM events
ORDER BY created_at DESC;

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

SELECT *
FROM (
    SELECT *
    FROM events
    ORDER BY created_at DESC
    LIMIT 10
) t
ORDER BY created_at DESC;

В этом случае сортировка в подзапросе используется для выбора нужных строк, а не для их отображения. Внутренний ORDER BY определяет, какие именно 10 строк попадут в подзапрос, а внешний ORDER BY задаёт порядок финального результата. Аналогичный принцип работает с оконными функциями:

SELECT id, user_id, created_at
FROM (
    SELECT
        id,
        user_id,
        created_at,
        ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY created_at DESC
        ) AS rn
    FROM events
) s
WHERE rn = 1;

Здесь ORDER BY влияет на вычисление ROW_NUMBER, то есть на логику нумерации строк внутри окна, но не определяет порядок вывода строк в результирующем наборе. 🔥 ORDER BY — это про порядок выдачи результата, а не про порядок хранения данных. Без внешнего ORDER BY СУБД не обязана возвращать строки в каком-либо определённом порядке. ➡️ SQL Ready | #практика