Серия «Аналитика FM»

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

Разберём целочисленное деление, работу с остатком и особенности дробных чисел.

В моем канале Аналитика FM выпуски про бизнесовые метрики в разных бизнесах, про особенности SQL запросов и работы аналитика.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Подписывайся, если интересно как устроен мир аналитика!

Целочисленное деление в PostgreSQL: куда пропадает дробная часть?

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

SELECT 10 / 3;

Какой результат ожидаем?

3.33?

А PostgreSQL вернёт:

3

Почему? Потому что оба числа - целочисленные (integer), а значит, PostgreSQL выполняет целочисленное деление.

При таком делении дробная часть отбрасывается, а не округляется.

1. Целочисленное и обычное деление

Посмотрим на несколько примеров:

SELECT 10 / 3 AS integer_division
, 10.0 / 3 AS decimal_division
, 10::numeric / 3 AS numeric_division;

Результат:

| integer_division | decimal_division | numeric_division |
|:-------------------------:|:---------------------------:|:---------------------------:|
| 3 | 3.333333... | 3.333333... |

В чём разница?

• 10 / 3 - оба операнда целые числа, поэтому результат целочисленный.

• 10.0 / 3 - число 10.0 имеет тип numeric, поэтому результат дробный.

• 10::numeric / 3 - мы явно преобразовали число в numeric.

💡 Важно: если привести результат к numeric уже после деления, дробная часть не вернётся!

SELECT (10 / 3)::numeric;
Результат:
3

Потому что сначала произошло целочисленное деление, и только потом преобразование типа.

Правильно:

SELECT 10::numeric / 3;

2. Отбрасывание дробной части - это не округление

Например:

SELECT 10 / 3 AS result_1,
11 / 3 AS result_2,
8 / 3 AS result_3;

Результат:

result_1 | result_2 | result_3
-------------+--------------+---------
3 | 3 | 2

PostgreSQL просто отбрасывает дробную часть.

Если нам нужно именно округление, используем ROUND():

SELECT ROUND(10::numeric / 3, 2);
Результат:
3.33

3. Деление с остатком

А теперь интереснее.

В PostgreSQL есть оператор %, который возвращает остаток от деления.

Например:

SELECT 10 / 3 AS division,
10 % 3 AS remainder;

Результат:

division | remainder
-------------+----------
3 | 1

Потому что:

10 = 3 * 3 + 1

То есть:

• / - целая часть результата деления для целочисленных операндов;

• % - остаток от деления.

Оператор % работает не только с целыми числами, но и с numeric.

Например:

SELECT 10.5 % 3;
Результат:
1.5

4. Где это может пригодиться?

Например, нам нужно определить, является ли число чётным.

Для этого достаточно проверить остаток от деления на 2:

SELECT number,
CASE WHEN number % 2 = 0 THEN 'Чётное'
ELSE 'Нечётное' END AS number_type
FROM numbers;

Или распределить пользователей по группам:

SELECT user_id, user_id % 3 AS group_number
FROM users;

Остаток позволяет распределять записи по группам, проверять кратность чисел и решать другие задачи.

5. Ещё один нюанс: отрицательные числа

Целочисленное деление в PostgreSQL отбрасывает дробную часть в сторону нуля.

SELECT -10 / 3 AS division,
-10 % 3 AS remainder;

Результат:

division | remainder
-------------+----------
-3 | -1

Проверка:

-10 = (-3) * 3 + (-1)

Обратите внимание: остаток в этом случае отрицательный.

🎯 Что важно запомнить

1. Если оба операнда целочисленные, PostgreSQL выполняет целочисленное деление.

2. Дробная часть отбрасывается, а не округляется.

3. Чтобы получить дробный результат, преобразуйте хотя бы один операнд в numeric или тип с плавающей точкой до деления.

4. ROUND() используется для округления результата.

5. Оператор % возвращает остаток от деления.

6. При работе с отрицательными числами целая часть отбрасывается в сторону нуля.

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

Ну а в моем канале Аналитика FM уже есть серия постов про AI-агентов.
Присоединяйся, если интересно разбираться в аналитике данных.

Если вы хоть немного следите за развитием искусственного интеллекта, то наверняка замечали: терминов становится всё больше.

И происходит путаница, подмена понятий. И вообще не понятно "что было первым: курица или яйцо"

В моем канале Аналитика FM выпуски про бизнесовые метрики в разных бизнесах, про особенности SQL запросов и работы аналитика.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
И серия постов про путь до ai агентов.
Подписывайся, если интересно как устроен мир аналитика!

Какие термины этого направления окружают нас:
- Машинное обучение
- Нейросети
- Deep Learning
- Generative AI
- Foundation Models
- LLM
- AI-ассистенты
- AI-агенты
- Multi-Agent Systems
- Agentic Systems

Иногда возникает ощущение, что все это - просто разные названия одного и того же.
Но это не так.

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

Как вообще дошли до AI-агентов?

Если сильно упростить историю, путь можно представить как движение от:

Научить компьютер находить закономерности

к:

Научить компьютер самостоятельно решать сложные задачи

Сначала компьютеры просто выполняли инструкции, которые заранее написал человек.

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

Затем развивались модели, способные работать с гораздо более сложными типами информации: изображениями, текстом, речью, видео.

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

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

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

Так постепенно мы пришли к тому, что сегодня называют AI-агентами.

Но модель и агент - это совсем не одно и то же

Представим обычную языковую модель.

Мы пишем:

Проанализируй эти данные и найди закономерности

Модель анализирует то, что ей дали, и возвращает ответ.

Теперь представим другую систему.

Мы говорим:

Каждое утро проверяй продажи. Если найдёшь аномалию - выясни причину и подготовь отчёт

Такая система уже может:

• получить данные

• обратиться к базе

• выполнить запрос

• проанализировать результат

• понять, что делать дальше

• использовать дополнительные инструменты

• проверить результат

• сформировать отчёт

• отправить его человеку

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

И именно этот переход сейчас особенно интересен.

Поэтому AI - это не одна технология

Когда мы говорим "искусственный интеллект", мы часто представляем что-то единое.
На практике это скорее большая экосистема.
Внутри неё находятся:

• методы обучения

• алгоритмы

• модели

• нейронные сети

• генеративные модели

• большие языковые и мультимодальные модели

• приложения

• ассистенты

• инструменты

• агенты

• системы из нескольких агентов

И всё это может работать вместе.

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

Поэтому, когда говорят:

Компания внедряет AI

это ещё почти ничего не говорит о том, что именно они внедряют.
Это может быть обычная ML-модель для прогнозирования.
Может быть генеративная модель.
Может быть чат-ассистент.
А может быть целая агентная система, которая выполняет бизнес-процесс.

Чем дальше мы двигаемся от модели к агентной системе, тем меньше AI выглядит как отдельный инструмент и тем больше - как участник рабочего процесса.

Модель:

отвечает.

Ассистент:

помогает.

Агент:

действует.

Агентная система:

может организовывать выполнение целого процесса.

Именно поэтому сейчас так много разговоров об AI-агентах.

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

Я как раз решил разобрать этот путь последовательно - от самых фундаментальных понятий до современных агентных систем.

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

📌 От машинного обучения и понятия модели - к нейросетям, генеративному AI, LLM, AI-приложениям, ассистентам, агентам и в итоге к Agentic Systems.

Подписывайся на мой телеграмм канала Аналитика FM!
Будем разбираться вместе!
Плюс там различные нюансы и особенности работы аналитика.

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

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

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

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

Или превращение длинной таблицы в широкую

В канале Аналитика FM я часто про это пишу - потому что аналитика заканчивается не на запросе, а на том, как ты показал результат.

Подписывайся!

Представь, у тебя есть данные:

| user_id | metric | value |
| ----------- | ------------- | -------- |
| 1 | revenue | 100 |
| 1 | orders | 2 |

Это длинная таблица.

Она удобна для хранения:

• гибкая

• легко добавлять новые метрики

• хорошо ложится в модели данных

Но попробуй быстро понять:

• кто сколько потратил

• у кого сколько заказов

• и сравнить это между собой

Неудобно.

А теперь та же информация:

| user_id | revenue | orders |
| ------------ | ------------- | ---------- |
| 1 | 100 | 2 |

Это широкая таблица.

И вот тут уже:

• метрики рядом

• сравнение - в одну секунду

• можно считать новые показатели

Что значит "превратить длинную таблицу в широкую"

Это значит:

взять значения из строк и разложить их по колонкам

То есть:

• metric → становится названиями колонок

• value → становится значениями в этих колонках

Ты буквально "разворачиваешь" данные.

Причём здесь pivot table

На самом деле, это и есть pivot.

Слово pivot - это "поворот".
Ты поворачиваешь таблицу так, чтобы:

• строки стали колонками

• данные стали наглядными

Если ты работал в Excel - ты это уже делал:
сводная таблица = pivot table.

В SQL это можно реализовать так:

SELECT
user_id,
SUM(CASE WHEN metric = 'revenue' THEN value END) AS revenue,
SUM(CASE WHEN metric = 'orders' THEN value END) AS orders
FROM table
GROUP BY user_id;

Зачем это вообще нужно

Потому что аналитика - это не про "достать данные".
Это про сделать их понятными.

Широкая таблица нужна, когда ты:

• строишь отчёт

• показываешь результат бизнесу

• считаешь метрики между собой

Длинная таблица - когда:

• хранишь данные

• работаешь с событиями

• строишь модели

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

Самая частая ошибка - пытаться всё делать в широком формате.

Это ломает гибкость:

• добавилась новая метрика → переписывай запрос

• данные перестают масштабироваться

Правильный подход:

• храним - в длинном виде

• показываем - в широком

Длинная таблица - это про хранение
Широкая таблица - это про понимание

И pivot - это просто инструмент, который помогает перейти от одного к другому.

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