JSONB в PostgreSQL: операторы и запросы к вложенным данным

Коротко

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

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

Какую задачу решает этот оператор

В PostgreSQL -> возвращает JSON-значение, ->> извлекает текст, #> и #>> работают с путём, @> проверяет содержимое. JSONB поддерживает индексы, но схема полей всё равно должна быть описана. Для частых метрик стабильные атрибуты лучше вынести в колонки или витрину.

properties->>'plan' вернёт текст и подходит для сравнения с 'pro'. Число из JSON нужно привести к numeric перед SUM. Проверка properties ? 'source' ищет наличие ключа, но не означает полнотекстовый поиск и не проверяет его тип.

Рабочий пример для аналитика

Составь каталог ключей и типов по событиям. Разделяй отсутствие ключа, JSON null и пустую строку. Извлекай поля в CTE, приводи типы и добавляй quality flags. Для массивов явно решай, нужен ли event-level результат или строка на каждый элемент.

Пример ниже намеренно оставляет явными период, ключи связи и уровень агрегации. Если заменить их на «как принято в базе», запрос может начать считать другую сущность. Сначала адаптируй названия колонок под свою схему, затем проверь результат на нескольких известных строках.

SELECT properties->>'plan' AS plan,
       (properties->>'discount')::numeric AS discount, COUNT(*) AS purchases
FROM events
WHERE event_name = 'purchase' AND properties ? 'source'
GROUP BY 1, 2 ORDER BY purchases DESC;

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

Первый тест — арифметический: совпадает ли число строк с ожидаемым зерном, а сумма подгрупп с общей суммой? Второй — поведенческий: что происходит на пустой группе, NULL, повторном событии и границе периода? Третий — сравнительный: можно ли получить тот же результат независимым способом на небольшом срезе?

Не ограничивайся тем, что запрос выполнился. Рабочий SQL должен быть объяснимым: другой аналитик понимает источник, фильтр, связь и причину выбранного оператора. Если результат меняется после добавления строки, зафиксируй, какое бизнес-правило это объясняет.

Для воспроизводимости сохрани рядом с запросом дату проверки, ожидаемый результат на контрольной выборке и версию определения метрики. Если SQL выполняется в BI, проверь, какие параметры подставляет интерфейс и не меняется ли часовая зона. Перед передачей запроса другому человеку убери неявные зависимости от сортировки, текущей даты и локальных настроек.

Зерно данных и границы расчёта

До запуска запроса выпиши, что означает одна строка в каждой таблице. В orders это может быть заказ, в order_items — позиция заказа, а в events — отдельное событие. Оператор работает поверх этого зерна: если соединить таблицы разных уровней без промежуточной агрегации, сумма и количество начнут отвечать уже на другой вопрос.

Зафиксируй период, часовую зону, статус записи и правило для повторов. Для событий важно отделить повторную отправку от двух реальных действий пользователя. Для денежных показателей нужно понять, входят ли скидки, возвраты и отмены. Эти условия должны быть видны в запросе или в названном CTE, а не жить только в голове автора.

Проверка на маленьком наборе

Сложный запрос стоит сначала проверить на пяти-десяти строках, где ответ можно посчитать вручную. Добавь один NULL, один дубль, одну строку ровно на границе периода и одну запись без связанной строки. Такой набор быстрее показывает ошибку в логике, чем просмотр тысячи строк в BI.

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

От запроса к рабочему решению

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

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

Как читать чужой SQL-запрос

Начинай не с отдельных операторов, а с внешнего результата. Найди SELECT, посмотри, какие поля группируются, затем поднимись к FROM и JOIN. У каждого источника подпиши примерное зерно и ожидаемую кардинальность связи. После этого проверь WHERE: он может убрать пользователей до расчёта, а может незаметно исключить строки, которые нужны для знаменателя.

Если в запросе есть CTE, читай их сверху вниз и фиксируй, что изменилось на каждом шаге: только названия, число строк, зерно или бизнес-смысл. Если есть окно, проверь PARTITION BY и ORDER BY. Если есть отрицательное условие, отдельно протестируй NULL. Такой порядок чтения помогает делать ревью по логике, а не спорить о стиле форматирования.

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

Что чаще всего ломается

->> всегда возвращает text. Сравнение числового параметра как строки может дать неверную сортировку. jsonb_array_elements размножает строки и может удвоить суммы. GIN-индекс не делает любой выраженный фильтр быстрым. Не прячь критическую метрику в JSON без владельца схемы.

Отдельно проверь изменение зерна после JOIN или разворачивания массива. Большая часть странных цифр появляется не из-за сложного синтаксиса, а потому что одна строка стала описывать два разных факта. Полезный приём — временно вывести ключ и посчитать COUNT(*) по нему до и после спорного шага.

Когда выбрать другой подход

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

Оператор не обязан быть единственным решением. Сравни альтернативу по трём критериям: совпадает ли смысл, видно ли зерно и можно ли проверить стоимость выполнения. Более короткий запрос не всегда лучше, если он прячет важное бизнес-правило или делает дубли незаметными.

Мини-практика

Собери таблицу свойств purchase events: plan, discount, source. Посчитай долю событий с отсутствующим ключом и сравни сумму discount до и после обработки NULL. Для массива items проверь количество строк до и после разворачивания.

После решения напиши короткое объяснение в формате: «одна строка результата — …; в числителе — …; знаменатель — …; период — …; потенциальное ограничение — …». Такой шаблон хорошо переносится в SQL-тренажёр, ревью и рабочий отчёт.

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

Вывод

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

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