Динамическая альтернатива pivot с CASE и GROUP BY

id    feh    bar
1     10     A
2     20     A
3      3     B
4      4     B
5      5     C
6      6     D
7      7     D
8      8     D

в следующем формате:

bar  val1   val2   val3
A     10     20 
B      3      4 
C      5        
D      6      7     8

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

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

• динамические сводные таблицы с JSON и PostgreSQL

использует новый PostgreSQL jsonb_object_agg функция для построения поворотных данных на лету в виде объекта JSON.

я буду использовать г-н Брандштеттер это "проще тест", чтобы проиллюстрировать:

CREATE TEMP TABLE tbl (row_name text, attrib text, val int);
INSERT INTO tbl (row_name, attrib, val) VALUES
   ('A', 'val1', 10)
 , ('A', 'val2', 20)
 , ('B', 'val1', 3)
 , ('B', 'val2', 4)
 , ('C', 'val1', 5)
 , ('D', 'val3', 8)
 , ('D', 'val1', 6)
 , ('D', 'val2', 7);

С помощью jsonb_object_agg функция, мы можем создать необходимый сводный набор результатов с этой выразительной красотой:

SELECT
  row_name AS bar,
  json_object_agg(attrib, val) AS data
FROM tbl
GROUP BY row_name
ORDER BY row_name;

выходы:

 bar |                  data                  
-----+----------------------------------------
 A   | { "val1" : 10, "val2" : 20 }
 B   | { "val1" : 3, "val2" : 4 }
 C   | { "val1" : 5 }
 D   | { "val3" : 8, "val1" : 6, "val2" : 7 }

как вы можете видеть, эта функция работает, создавая пары ключ / значение в объекте JSON из attrib и value столбцы в образце данных, сгруппированные по row_name.

хотя этот результирующий набор, очевидно, выглядит по-другому, я считаю, что он действительно удовлетворит многие (если не большинство) реальных случаев использования, особенно те, где данные требуют динамически генерируемого разворота, или где результирующие данные потребляются родительским приложением (например, необходимо переформатировать для передачи в http-ответе).

преимущества такого подхода:

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

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

• обрабатывает большое количество столбцов. поскольку сводные данные сохраняются как один столбец jsonb, вы не столкнетесь с ограничением столбца PostgreSQL (≤1,600 столбцов, я считаю). Существует еще ограничение, но я считаю, что это то же самое, что и для текстовых полей: 1 ГБ на созданный объект JSON (пожалуйста, исправьте меня, если я ошибаюсь). Это много пары ключ/значение!

• упрощенная работа с данными. я считаю, что создание данных JSON в БД упростит (и, вероятно, ускорит) процесс преобразования данных в родительских приложениях. (Вы заметите, что целочисленные данные в нашем тестовом примере были правильно сохранены как таковые в результирующих объектах JSON. PostgreSQL обрабатывает это путем автоматического преобразования своих внутренних типов данных в JSON в соответствии со спецификацией JSON.) Эта воля эффективно устраните необходимость ручного приведения данных, передаваемых родительским приложениям: все это можно делегировать собственному парсеру JSON приложения.

различия (и возможные ошибки):

• это выглядит по-другому. нельзя отрицать, что результаты этого подхода выглядят по-другому. Объект JSON не так красив, как результирующий набор перекрестных таблиц; однако различия являются чисто косметическими. Тот же информация производится и в формате, который, вероятно,больше дружелюбный для потребления родительского приложения.

• отсутствуют ключи. отсутствующие значения в подходе перекрестной таблицы заполняются нулями, в то время как объекты JSON просто отсутствуют применимые ключи. Вам придется решить для себя, Является ли это приемлемым компромиссом для вашего случая использования. Мне кажется, что любая попытка решить эту проблему в PostgreSQL будет значительно усложняют процесс и, вероятно, предполагают некоторую интроспекцию в виде дополнительных запросов.

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

вывод

мне очень любопытно услышать мнения других (особенно @Erwinbrandstetter'S) об этом подходе, особенно в том, что касается производительности. Когда я обнаружил этот подход в блоге Эндрю Бендера, это было похоже на удар в висок. Какой прекрасный способ по-новому подойти к сложной проблеме в PostrgeSQL. Он отлично решил мой вариант использования, и я считаю, что он также будет служите и многим другим.