## 7 полезных приёмов для Oracle SQL

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

1) Фильтрованные (partial) индексы
В Oracle можно создавать индексы только для подмножества строк, чтобы ускорить выборку по популярным условиям.

CREATE INDEX idx_orders_high_value
  ON orders(order_date)
  WHERE total_amount > 1000;

2) Функциональные (function-based) индексы
Если фильтруете или джойните по функции, создайте индекс прямо по выражению:

CREATE INDEX idx_orders_year
  ON orders (EXTRACT(YEAR FROM order_date));

3) GROUPING SETS, ROLLUP, CUBE
Для одновременной агрегации по нескольким группировкам без UNION ALL:

SELECT region, category, SUM(sales) AS total
FROM sales
GROUP BY ROLLUP (region, category);

4) Материализованные представления с QUERY REWRITE
В Oracle можно сделать автоматическую подмену сложного запроса предрасчитанным результатом (материализованным представлением):

CREATE MATERIALIZED VIEW mv_sales_by_month
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
ENABLE QUERY REWRITE
AS
SELECT TRUNC(order_date, 'MM') AS month, SUM(total_amount) AS total
FROM orders
GROUP BY TRUNC(order_date, 'MM');

Теперь запрос SELECT month, SUM(total_amount) FROM orders GROUP BY month; автоматически будет использовать mv_sales_by_month.

5) WITH PL/SQL FUNCTION RESULT CACHE
Кэшируйте результат функции, чтобы при одинаковых входных данных не пересчитывать:

CREATE OR REPLACE FUNCTION get_tax_rate(p_region VARCHAR2)
RETURN NUMBER RESULT_CACHE RELIES_ON (tax_table) IS
  v_rate NUMBER;
BEGIN
  SELECT rate INTO v_rate FROM tax_table WHERE region = p_region;
  RETURN v_rate;
END;

6) PARALLEL HINT для ускорения запросов
Явно указывайте параллельное выполнение запроса, чтобы задействовать несколько процессов:

SELECT /*+ PARALLEL(orders, 4) */ customer_id, SUM(total_amount)
FROM orders
GROUP BY customer_id;

7) DBMS_STATS.AUTO_SAMPLE_SIZE для сбора статистики
Используйте автоматический подбор размера выборки для более точной оптимизации плана выполнения:

EXEC DBMS_STATS.GATHER_TABLE_STATS('HR', 'ORDERS', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE);

• Совет: проверяйте планы выполнения через DBMS_XPLAN.DISPLAY_CURSOR, чтобы видеть реальные шаги запроса, а не только предполагаемые.

@sqlhub

📜 История SQL — от лабораторной идеи до «языка данных» № 1

Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках.

1. Всё началось с таблицы на бумаге

- 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*.
- В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl).
- Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике.

2. SEQUEL — «английский» запрос к таблицам

- 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R.
- Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL.
- Ключевая фишка — запросы выглядят почти как английские предложения:

    SELECT name, salary
      FROM employees
     WHERE dept = 'R&D';
      

- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге.

3. Почему SEQUEL стал SQL

- Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*.
- IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language).
- *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».*

4. Коммерческий взлёт


- 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий |
- 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок
- 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется
- 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке

5. Стандартизация и эволюция

- ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs).
- Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х.

6. Забавные факты, которые украсят small talk 🍸

1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры.
2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах.
3. Команда GO в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql.
4. В Oracle долго не было LIMIT, а в MySQL —QL — от лабора Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`».
5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000.
6. SQL — декларативный язык, но внутри СУБД каждый SELECT превращается в процедурный план.
7.Ф. Кодд публикуетпридумали позже, чемлабораторн Сначала удалять целую БД казалось слишком опасным.

7. Почему SQL живёт дольше модных NoSQL‑наследников

- Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией.
- Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB.
- Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект.
- Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер SELECT ….

Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в FROM.

https://www.youtube.com/shorts/EuFjzuVHkHE

@sqlhub -подписаться

🧩 Задача для SQL-аналитиков: "Пропавшие продажи"

📖 Описание задачи

У вас есть таблица sales, где хранятся данные о продажах:

CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    product_id INT,
    quantity INT,
    price DECIMAL(10,2)
);

INSERT INTO sales (sale_id, sale_date, product_id, quantity, price) VALUES
(1, '2024-01-01', 101, 1, 100.00),
(2, '2024-01-02', 102, 2, 150.00),
-- ...
-- остальные данные
;

Каждый день формируется отчёт, где суммируются продажи по дням:

SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;

✅ Вчера сумма в отчёте была 1,000,000. Сегодня — 980,000, хотя новых записей не удаляли.

📝 Ваша задача:

1. Найти, какие записи "исчезли" из отчёта, если данных в таблице sales фактически не удаляли.
2. Определить, почему эти записи больше не попадают в итоговый запрос.
3. Исправить отчёт, чтобы сумма снова стала 1,000,000.

Ограничения:

- Таблица не изменилась по количеству строк.
- Никто не менял код запроса.
- sale_date, quantity, price остались без изменений.

Подсказка: возможно, дело в NULL, JOIN или неправильной агрегации.

🕵️ Что проверяет задача:

- Знание SQL-агрегации
- Понимание NULL и работы SUM
- Умение анализировать запросы «не через код», а через их результат
- Навык находить «скрытые» ошибки данных (например, sale_date стал NULL)

💡 Решение:

При проверке выяснится, что часть записей имеет `sale_date = NULL` (например, кто-то обновил поле sale_date на NULL).

Итоговый запрос:

```sql
SELECT sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY sale_date;
```

не учитывает строки, где `sale_date IS NULL`, потому что GROUP BY игнорирует NULL как отдельную группу (не попадает ни в один существующий `sale_date`).

Чтобы увидеть эти записи:

```sql
SELECT sale_date, COUNT(*), SUM(quantity * price)
FROM sales
GROUP BY sale_date;
```

Для восстановления суммы нужно добавить обработку NULL, например:

```sql
SELECT COALESCE(sale_date, 'unknown') AS sale_date, SUM(quantity * price) AS total_sales
FROM sales
GROUP BY COALESCE(sale_date, 'unknown');
```

✅ Теперь сумма снова будет 1,000,000, а "пропавшие" продажи попадут в отдельную категорию unknown.

🎯 Эта задача учит:

✅ Всегда думать о данных, а не только о коде
✅ Проверять поля на NULL даже там, где их не ожидаешь
✅ Уметь объяснять ошибки «бизнес-заказчику», а не только исправлять запрос

🔥 Отличная тренировка внимательности и понимания нюансов SQL-агрегации!

@sqlhub

💫 GlueSQL — SQL-движок, превращающий любые данные в полноценную базу данных. Этот инструмент умеет выполнять JOIN между CSV и MongoDB, работать с Git как с хранилищем данных и даже запускать SQL-запросы прямо в браузере через WebAssembly.

Что отличает GlueSQL от классических СУБД?
- Поддержка schemaless-данных
- Встроенные адаптеры для 10+ форматов
- Возможность добавлять свои хранилища через реализацию двух traits на Rust

Проект активно развивается: недавно добавили поддержку транзакций в Sled-бэкенде и анонсировали облачную версию. Для теста достаточно cargo add gluesql и уже можно писать SQL-запросы к данным в памяти.

🤖 GitHub

@sqlhub

🛢️ SQL-задача с подвохом: GROUP BY и скрытая ловушка

Условие:

Есть таблица orders:

| id | customer_id | amount | status |
|-----|-------------|--------|-----------|
| 1 | 101 | 200 | completed |
| 2 | 102 | 150 | NULL |
| 3 | 101 | 300 | completed |
| 4 | 103 | NULL | completed |
| 5 | 102 | 100 | completed |
| 6 | 101 | 250 | NULL |

Задача: найти всех клиентов, у которых сумма заказов больше 500.

Ты пишешь запрос:

SELECT customer_id, SUM(amount) as total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 500;

❓ Вопрос:
Какие клиенты вернутся? Есть ли тут подвох? Что произойдёт с заказами, где amount или status — NULL?

🔍 Подвох:

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

1️⃣ Что происходит с NULL в `amount`?

В SQL агрегатные функции (например, SUM) игнорируют NULL значения. Это значит:

- Заказ id=4 (`amount = NULL`) не участвует в суммировании.
- Заказ id=6 (`amount = 250`) участвует, потому что amount не NULL.

2️⃣ Считаем по каждому клиенту:

- customer_id=101:
- id=1: 200
- id=3: 300
- id=6: 250
Итого: 200 + 300 + 250 = 750

- customer_id=102:
- id=2: 150
- id=5: 100
Итого: 150 + 100 = 250

- customer_id=103:
- id=4: NULL (игнорируется)
Итого: 0

3️⃣ Кто попадёт в результат:

Только customer_id=101 (с суммой 750 > 500).

---

✅ Результат:

| customer_id | total |
|-------------|--------|
| 101 | 750 |

---

💥 Подвох #2:

Допустим ты случайно написал:

HAVING SUM(amount) IS NOT NULL AND SUM(amount) > 500;

Кажется логичным? А вот нет: SUM всегда возвращает 0 (не NULL), даже если у клиента нет заказов с ненулевой суммой.

➡️ Даже клиент с только NULL значениями (например, customer_id=103) получит SUM(amount) = 0, а не NULL.

Это частая ловушка:
COUNT, SUM, AVG игнорируют NULL внутри, но результат НЕ NULL (обычно 0 или NULL в зависимости от агрегата).

---

🛠 Что ещё важно:

• Если хочешь учитывать только выполненные заказы (status = 'completed'), нужно добавить:

WHERE status = 'completed'

⚠️ Не пиши условие в HAVING для фильтрации строк — лучше фильтровать через WHERE до группировки.

✅ Вывод:

- ✅ Агрегатные функции типа SUM игнорируют NULL внутри группы.
- ✅ SUM возвращает 0, даже если все значения NULL (НЕ NULL, как думают многие).
- ✅ HAVING применяется ПОСЛЕ группировки, а WHERE — ДО.
- ✅ Ошибки часто возникают, если условие на фильтр пишут в HAVING вместо WHERE.

💡 Бонус-вопрос:
Что будет, если заменить SUM(amount) на COUNT(amount) в SELECT и HAVING? И как это повлияет на клиентов с NULL значениями?

@sqlhub

🧠 SQL-задача с подвохом (Oracle)

Тема: оконные функции, группировка, ловушка в агрегатах

📌 Задача:

Есть таблица SALES со следующей структурой:

CREATE TABLE SALES (
  ID         NUMBER,
  REGION     VARCHAR2(20),
  SALE_DATE  DATE,
  AMOUNT     NUMBER
);

Пример данных:

| ID | REGION | SALE_DATE | AMOUNT |
|----|--------|-----------|--------|
| 1 | North | 01-JAN-24 | 100 |
| 2 | North | 02-JAN-24 | 120 |
| 3 | South | 01-JAN-24 | 90 |
| 4 | South | 03-JAN-24 | 200 |
| 5 | East | 01-JAN-24 | 150 |
| 6 | East | 02-JAN-24 | 100 |

🧩 Найти:
Для каждого региона — ту дату, в которую была вторая по величине сумма продаж.
Если в регионе меньше двух дат — не выводить его вовсе.

🎯 Подвох:
- нельзя использовать LIMIT, FETCH FIRST, QUALIFY и подзапросы с ROWNUM напрямую (нужно решение через оконные функции Oracle)
- многие пытаются взять MAX(AMOUNT) с OFFSET 1, но в Oracle это не так просто

✅ Ожидаемый результат:

| REGION | SALE_DATE | AMOUNT |
|--------|-----------|--------|
| North | 01-JAN-24 | 100 |
| South | 01-JAN-24 | 90 |
| East | 02-JAN-24 | 100 |

🔍 Решение:

```sql
SELECT REGION, SALE_DATE, AMOUNT
FROM (
SELECT
REGION,
SALE_DATE,
AMOUNT,
DENSE_RANK() OVER (PARTITION BY REGION ORDER BY AMOUNT DESC) AS rnk,
COUNT(DISTINCT SALE_DATE) OVER (PARTITION BY REGION) AS cnt
FROM SALES
)
WHERE rnk = 2 AND cnt >= 2;
```

📌 **Объяснение подвоха:**
- `DENSE_RANK` гарантирует, что если есть одинаковые суммы, они получат один и тот же ранг
- `COUNT(DISTINCT SALE_DATE)` проверяет, что у региона хотя бы две разные даты (иначе регион исключается)
- Работает чисто на оконных функциях, без подзапросов с ROWNUM — идеально для Oracle

🧪 Проверь результат и попробуй адаптировать под похожие задачи с TOP-N логикой.

@sqlhub

🧠 SQL-задача с подвохом: “Самый активный — или самый невидимый?”

📘 Условие

У тебя есть две таблицы:

users(id, name)
posts(id, user_id, title)

Вопрос:
Выведи всех пользователей, у которых нет ни одного поста,
а также пользователя, у которого больше всего постов.

📌 Но — в одном запросе.

❓ Попробуй решить задачу таким SQL:

SELECT u.name, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.name
HAVING COUNT(p.id) = 0 OR COUNT(p.id) = (
    SELECT MAX(cnt)
    FROM (
        SELECT COUNT(*) AS cnt
        FROM posts
        GROUP BY user_id
    ) t
);

🔍 Вопрос:

1) Почему он может вернуть неправильный результат?
2) В чём разница между COUNT(*) и COUNT(p.id)?
3) Как переписать его правильно?

✅ Разбор подвоха

💣 Подвох 1: COUNT(p.id) пропускает NULL

Когда ты делаешь LEFT JOIN, для пользователей без постов p.id = NULL.

• COUNT(*) считает все строки (включая NULL)
• COUNT(p.id) не считает строки, где p.id IS NULL

👉 Это может привести к тому, что:
• COUNT(p.id) = 0 — действительно "нет постов"
• но в подзапросе SELECT COUNT(*) считает иначе и даёт искаженную MAX(cnt)

🔁 Как правильно:

1) Подзапрос должен использовать COUNT(p.id), чтобы сравнение было честным
2) Либо использовать JOIN вместо LEFT JOIN в подзапросе, чтобы не попасть на "нулевых" пользователей

✅ Финальный корректный запрос:

SELECT u.name, COUNT(p.id) AS post_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.name
HAVING COUNT(p.id) = 0
   OR COUNT(p.id) = (
       SELECT MAX(cnt)
       FROM (
           SELECT user_id, COUNT(p.id) AS cnt
           FROM posts
           GROUP BY user_id
       ) AS ranked
   );

🎯 Такой запрос честно покажет:

• Всех “молчунов” (0 постов)
• И самого активного автора (макс постов)

📌 Отлично подходит для собеседования или тех, кто считает, что "GROUP BY — это просто".
@sqlhub

Если вы размышляете, как усилить своё резюме, наш совет — освойте SQL. Это язык, который помогает извлекать ценную информацию из массивов данных.

Познакомиться с инструментом можно на бесплатном курсе «Введение в SQL и работу с базой данных». За 5 занятий вы научитесь создавать, редактировать и обновлять базы данных, сделаете свои первые запросы и отчёты.

Курс будет полезен даже тем, кто пока не собирается становиться аналитиком. Научитесь применять SQL в своих задачах — с ним вы сможете больше – https://netolo.gy

Реклама. ООО "Нетология". ИНН 7726464125 Erid: 2VSb5y1d224

🦦 Walrus — удобная обёртка над Redis для Python-разработчиков. Этот проект расширяет стандартный клиент redis-py, добавляя к нему набор полезных абстракций для работы с Redis.

Вместо того чтобы заставлять изучать новый API, Walrus предлагает привычный интерфейс с дополнительными возможностями. При этом проект остаётся лёгковесным и сохраняет совместимость с альтернативными Redis-подобными базами вроде rlite.

🤖 GitHub

@sqlhub

🐘 Slonik — проверенный клиент PostgreSQL для Node.js с строгой типизацией и детальным логированием. Этот инструмент решает проблему безопасности и предсказуемости работы с SQL-запросами: вместо ручного формирования запросов проект заставляет использовать литералы с автоматическим экранированием параметров.

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

🤖 GitHub

@sqlhub

🗂️ BRModelo Web — веб-приложение для проектирования баз данных. Этот open-source проект позволяет создавать ER-диаграммы прямо в браузере с экспортом в SQL-скрипты.

Инструмент имеет образовательную направленность. Интерфейс на португальском и английском языках адаптирован для учебных задач: есть подсветка сущностей, автоматическая расстановка связей и валидация схемы. Запустить локальную копию можно через Node.js + MongoDB или Docker-контейнеры.

🤖 GitHub

@sqlhub

В мире, где данные — это новая валюта, каждый специалист должен уметь работать с ними на высшем уровне. Особенно — аналитики.

Сделать уверенный старт в профессии можно на курсе «Аналитик данных» от karpovꓸcourses. Вы узнаете, как наводить порядок в потоке данных, выявлять скрытые связи, превращать хаотичные цифры в понятные факты и точные решения, которые помогают бизнесу двигаться вперед.

На курсе есть все, что нужно для эффективной работы с данными: от Python и SQL до BI-инструментов и создания дашбордов.

С 12 по 31 мая погружаться в аналитику еще выгоднее. При покупке курса «Аналитик данных» и симулятора A/B-тестов вы получите скидку 10%. А главное, сразу усилите резюме ценными навыками.

Реклама. ООО «Карпов Курсы», ИНН: 7811764627, erid: 2VtzqunnpSp

🐘 pgBackRest — надежное решение для резервного копирования PostgreSQL. В отличие от стандартных утилит, pgBackRest предлагает параллельное выполнение операций, поддержку инкрементных бэкапов на уровне блоков и встроенную проверку целостности через контрольные суммы.

Особого внимания заслуживает гибкость развертывания: резервные копии можно хранить локально, на удаленных серверах через SSH/TLS или в облачных хранилищах S3/Azure/GCS. Система автоматически управляет ротацией архивов и обеспечивает консистентность данных даже при аварийном завершении работы.

🤖 GitHub

@sqlhub

Истории, после которых ты захочешь уволиться

Ты правда думал, что так и будешь сидеть в найме до пенсии?

А потом читаешь пост какого-то чувака из IT и ловишь: “бл*, я тоже так хочу”.

В этом канале бывший дата саентист — Глеб Михайлов. Он уволился из Яндекса, послал всё на*** и теперь пишет как есть:

– про выгорание,
– про деньги, свободу и зашквар,
– и как из всего этого лепить свою жизнь.

Топ постов канала:

👉 7 лет отсидки (https://www.tg-me.com/mikhaylovgleb/336) (в офисе)
👉 Страшно – пи***ц (https://www.tg-me.com/mikhaylovgleb/302)
👉 Робот-пылесос для денег (https://www.tg-me.com/mikhaylovgleb/347)

Подпишись - https://www.tg-me.com/mikhaylovgleb, если тоже устал терпеть.

Тут честно, смешно и немного больно — как в жизни.


Реклама

🛠️ История создания “storage-agnostic” message queue


Контекст:
Работая на Go, автор вдохновился инструментами из Node.js экосистемы (BullMQ, RabbitMQ) и захотел сделать что-то похожее, но с нуля, без зависимостей. Так родилась идея — сначала он создал Gocq (Go Concurrent Queue): простую concurrent-очередь, работающую через каналы.

⚡ Основная проблема

Gocq отлично работал в памяти, но не поддерживал устойчивое хранение задач.
Автор задумался: а можно ли сделать очередь, не зависящую от конкретного хранилища — так, чтобы её можно было подключить к Redis, SQLite или совсем без них?

🧱 Как это реализовано в VarMQ

После рефакторинга Gocq был разделён на два компонента:
1) Worker pool — пул воркеров, обрабатывающих задачи
2) Queue interface — абстракция над очередью, не зависящая от реализации

Теперь воркер просто берёт задачи из очереди, не зная, где они хранятся.

🧠 Пример использования

• In-memory очередь:

w := varmq.NewVoidWorker(func(data any) {
   // обработка задачи
}, 2)
q := w.BindQueue()

• С SQLite-поддержкой:

import "github.com/goptics/sqliteq"

db := sqliteq.New("test.db")
pq, _ := db.NewQueue("orders")
q := w.WithPersistentQueue(pq)

• С Redis (для распределённой обработки):

import "github.com/goptics/redisq"

rdb := redisq.New("redis://localhost:6379")
pq := rdb.NewDistributedQueue("transactions")
q := w.WithDistributedQueue(pq)

В итоге воркер обрабатывает задачи одинаково — независимо от хранилища.

✅ Почему это круто

• Гибкость: адаптеры позволяют легко менять хранилище без правок воркера
• Минимальные зависимости: в яд

📌 Читать

🧠 Уровень Pro: Медиана, ранги и NULL в Oracle SQL

📋 Есть таблица sales:

CREATE TABLE sales (
  salesman_id NUMBER,
  region VARCHAR2(50),
  amount NUMBER
);

📦 Данные:

| salesman_id | region | amount |
|-------------|------------|--------|
| 101 | 'North' | 200 |
| 101 | 'North' | NULL |
| 102 | 'North' | 150 |
| 103 | 'North' | NULL |
| 104 | 'South' | 300 |
| 105 | 'South' | NULL |
| 106 | 'South' | 50 |
| 107 | 'South' | NULL |

🎯 Задача 2.0:
Вывести salesman_id, чья сумма продаж меньше медианы по региону,
и показать ранг продавца внутри региона по сумме продаж, где NULL = 0.

⚠ Подвохи:
- MEDIAN() доступен только в Oracle.
- Нужно предварительно агрегировать суммы.
- Продавцы с только NULL-продажами = 0.
- Ранг должен учитывать правильную сортировку и связи с регионом.

✅ Решение:

```sql
WITH sales_total AS (
SELECT
salesman_id,
region,
NVL(SUM(amount), 0) AS total_sales
FROM sales
GROUP BY salesman_id, region
),
region_median AS (
SELECT
region,
MEDIAN(total_sales) AS region_median
FROM sales_total
GROUP BY region
),
ranked AS (
SELECT
st.salesman_id,
st.region,
st.total_sales,
r.region_median,
RANK() OVER (PARTITION BY st.region ORDER BY st.total_sales DESC) AS sales_rank
FROM sales_total st
JOIN region_median r ON st.region = r.region
)
SELECT *
FROM ranked
WHERE total_sales < region_median;
```

🧠 Объяснение:

1. `sales_total`: агрегируем продажи по продавцу, `NULL → 0`
2. `region_median`: считаем **медиану** продаж по каждому региону
3. `ranked`: добавляем `RANK()` по убыванию продаж внутри региона
4. Финальный фильтр: продажи ниже медианы

🔍 Пример вывода:

| salesman_id | region | total_sales | region_median | sales_rank |
|-------------|--------|-------------|----------------|-------------|
| 105 | South | 0 | 50 | 3 |
| 107 | South | 0 | 50 | 3 |
| 103 | North | 0 | 150 | 3 |

📌 Польза:

✅ Отлично проверяет:
- знание оконных функций
- работу с медианой
- поведение `NULL` в агрегатах
- построение CTE-цепочек и аналитики

🔁 Можно расширить:
- Добавить ранги *по убыванию и по возрастанию*
- Вместо `MEDIAN()` использовать `PERCENTILE_CONT()`
- Построить дэшборд: кто всегда "ниже медианы" за месяц

@sqlhub