Делаю заполнение демо-данными, для этого составляю схему. Джойны джойнов, от которых рябит в глазах.

Представьте дерево. У него есть корень, от него отходят ветки, от больших веток - более мелкие, а затем листья.

Примерно так же устроены иерархические справочники в информационных системах.
И как же можно понять: что есть ветка, а что есть лист в этом иерархическом справочнике?

В канале Аналитика FM я часто разбираю такие ситуации - когда задача вроде решаема, но без нормальной структуры превращается в кашу.

Например:

📁 Транспорт
├── Легковой транспорт
│ ├── Седаны
│ └── Кроссоверы
└── Грузовой транспорт
 ├── Малотоннажный
 └── Тягачи

Или:

📁 Товары
├── Электроника
│ ├── Телефоны
│ └── Ноутбуки
└── Бытовая техника
 ├── Холодильники
 └── Стиральные машины

А как такое дерево хранится в базе данных?

На самом деле всё гораздо проще, чем кажется.

Обычно таблица справочника выглядит примерно так:

| id | name | parent_id |
| --- | ----------------------------------- | --------------- |
| 1 | Транспорт | NULL |
| 2 | Легковой транспорт | 1 |
| 3 | Грузовой транспорт | 1 |
| 4 | Седаны | 2 |
| 5 | Кроссоверы | 2 |
| 6 | Тягачи | 3 |

Структурно это выглядит так:
1 Транспорт
├── 2 Легковой транспорт
│ ├── 4 Седаны
│ └── 5 Кроссоверы
└── 3 Грузовой транспорт
└── 6 Тягачи

Каждая запись имеет:

• id - собственный идентификатор;

• parent_id - идентификатор родительского элемента.

Например:

id = 4
name = Седаны
parent_id = 2

Это означает:

Седаны → Легковой транспорт → Транспорт

Именно благодаря полю parent_id база понимает, что "Седаны" и "Кроссоверы" относятся к одной ветке дерева.

Если подниматься по родителям вверх, то рано или поздно мы придём к общему узлу - корню ветки.

Получается, что вся иерархия строится буквально на одном поле: parent_id

Для чего нужны иерархические справочники?

Они позволяют хранить данные не просто списком, а показывать связи между объектами.

Благодаря этому можно:

✅ группировать данные;
✅ строить отчёты по категориям;
✅ наследовать свойства от родительских узлов;
✅ задавать правила сразу для целой ветки;
✅ быстро находить все дочерние элементы.

Например, если правило применяется ко всей категории "Легковой транспорт", то оно автоматически действует и для седанов, и для кроссоверов, и для любых новых подкатегорий, которые появятся позже.

Где используются?

📌 MDM-системы (Master Data Management);
📌 каталоги товаров интернет-магазинов;
📌 банковские и страховые системы;
📌 ERP и CRM;
📌 классификаторы услуг и продуктов;
📌 организационная структура компании;
📌 государственные классификаторы и справочники.

Преимущества

✔ Гибкость. Можно добавлять новые ветки без изменения структуры данных.

✔ Удобная аналитика. Легко получить данные как по конкретному элементу, так и по всей категории.

✔ Наследование правил. Одно правило может применяться сразу к тысячам объектов.

✔ Масштабируемость. Структура может содержать десятки и сотни уровней вложенности.

Недостатки

❌ Сложность запросов. Иногда, чтобы найти всех потомков или родителей, приходится строить рекурсивные запросы.

❌ Производительность. Глубокие иерархии могут существенно замедлять выполнение запросов.

❌ Риск циклических ссылок. Если по ошибке сделать узел потомком самого себя, можно получить бесконечный цикл.

❌ Сложность сопровождения. Изменение структуры верхних уровней может затронуть большое количество дочерних элементов.

Как с ними работать?

При работе с иерархическими справочниками чаще всего приходится решать четыре задачи:

🔹 найти всех потомков узла;
🔹 найти всех родителей элемента;
🔹 определить, принадлежит ли элемент определённой ветке;
🔹 определить, к какому верхнему узлу относится конкретный элемент.

В Oracle для этого используются специальные иерархические запросы:

START WITH ...
CONNECT BY ...

Именно они позволяют "обходить дерево" вверх или вниз по веткам.

В канале Аналитика FM (клик :-) ) уже готов пост про конструкцию START WITH и CONNECT BY.

Подписывайся, если интересно разбираться в особенностях работы аналитика.

Иерархический справочник - это не просто список значений. Это способ описать реальные взаимосвязи между объектами и сделать систему более гибкой и управляемой.

А одна маленькая колонка parent_id превращает обычную таблицу в целое дерево данных.

Если ты когда-нибудь писал длинный SQL-запрос и в какой-то момент ловил себя на мысли:
"Я уже сам не понимаю, что здесь происходит" - поздравляю, ты подошёл к моменту, где появляются временные таблицы.

В канале Аналитика FM я часто разбираю такие ситуации - когда задача вроде решаема, но без нормальной структуры превращается в кашу.

Что такое временная таблица

Это обычная таблица…
только с одним отличием:

👉 она живёт временно и потом исчезает

Ты создаёшь её:

• чтобы сохранить промежуточный результат

• поработать с ним

• и не засорять основную базу

Тебе нужно:

• взять заказы

• отфильтровать только оплаченные

• посчитать выручку

• добавить сегментацию пользователей

• ещё пару условий сверху

Можно написать один огромный запрос.

А можно сделать по-другому:

1. Сначала собрать "чистые заказы"

2. Потом на их основе считать метрики

3. Потом добавлять бизнес-логику

И вот тут временные таблицы начинают играть.

Как это выглядит

CREATE TEMP TABLE temp_orders AS
SELECT *
FROM orders
WHERE status = 'paid';

Создаем промежуточный слой данных.

А потом работаем уже с ним.

SELECT user_id, SUM(amount)
FROM temp_orders
GROUP BY user_id;

Зачем это нужно

1️⃣ Разделить сложную логику

Вместо одного "монстра":

• ты разбиваешь задачу на шаги

• каждый шаг понятен

• легче дебажить

2️⃣ Переиспользовать результат

Если один и тот же кусок данных нужен несколько раз:

• не нужно каждый раз пересчитывать

• можно сохранить и использовать

3️⃣ Ускорить запросы

Иногда:

• тяжёлый JOIN

• сложная фильтрация

👉 выгодно посчитать один раз и сохранить результат

4️⃣ Не засорять базу

Если ты создашь обычную таблицу:

• она останется

• её надо потом удалять

• она может мешать другим

Временная таблица:

• живёт в рамках сессии

• автоматически исчезает

Когда это особенно полезно

• сложные аналитические расчёты

• многоступенчатые преобразования данных

• работа с "грязными" данными

• отладка логики

Важный нюанс

Временные таблицы - это не единственный инструмент.

Есть ещё:

• CTE (WITH)

• подзапросы

Но:

👉 CTE - это "логика в одном запросе"
👉 временные таблицы - это "разбивка на реальные шаги"

Иногда CTE читается тяжело.
А временные таблицы дают ощущение "пайплайна".

Где часто ошибаются

• создают временные таблицы без необходимости

• забывают, что они завязаны на сессию

• используют их там, где проще CTE

То есть это инструмент - не серебряная пуля.

Самая простая мысль

Временная таблица - это способ остановиться посередине запроса и зафиксировать результат

И иногда именно это спасает:

• читаемость

• производительность

• и твои нервы

В канале Аналитика FM (клик :-) )я рассказываю про продуктовые метрики в разных бизнесах. В чем особенности и нюансы. Серия постов про средний чек уже готова.

Подписывайся, если интересно интересно разбираться в особенностях работы аналитика.