Разве JSONB делает массивы PostgreSQL бесполезными?

Question

Предположим, что вы хотите сохранить «теги» на своем объекте (скажем, сообщение). С выпуском 9.4 у вас есть 3 основных варианты:

• теги как текст []
• тегов как jsonb
• тегов как текст (и запоминание JSON строка в виде текста)

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

Итак, выбор в основном между text[] и jsonb. Оба могут быть запрошены.
Что вы бы использовали? И почему?

Answer 1

В большинстве случаев я хотел бы использовать normalized schema с таблицей option_tag реализующей многие-ко-многим между таблицами option и tag. Ссылка реализация здесь:

• How to implement a many-to-many relationship in PostgreSQL?

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

Для полноты добавить в список опций:

• hstore (хороший вариант)
• xml более многословным и более сложным, чем любой hstore или jsonb, поэтому я хотел бы использовать его только при работе с XML ,
• «строка значений, разделенных запятыми» (очень простой, в основном плохой вариант)
• EAV (Entity-Attribute-Value) или «пары имя-значение» (в основном плохой вариант)
  детали под этим смежный вопрос о dba.SE:
  • Is there a name for this database structure?

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

Прочитать blog entry by Josh Berkus с помощью ссылки @a_horse в своем комментарии. Но имейте в виду, что он фокусируется на выбранных случаях чтения. Джош уступает:

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

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

jsonb - это только хороший вариант, если вы собираетесь работать с JSON в любом случае и можете хранить и извлекать JSON «как есть».

Answer 2

Я использовал как нормализованную схему, так и просто поле text с CSV-разделителями вместо пользовательских типов данных (вместо CSV вы можете использовать JSON или любую другую кодировку, такую ​​как www-urlencoding или даже кодирование атрибутов XML). Это связано с тем, что многие библиотеки ORM и базы данных не очень хорошо поддерживают настраиваемые типы данных (hstore, jsonb, array и т. Д.).

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

Это означает, что я рекомендую использовать Solr (или elasticsearch) для запроса тегов, поскольку он имеет дело с количеством тегов и общим префиксом тегов, намного лучше, чем то, что я мог бы получить Postgres, если вы готовы иметь дело с аспектами согласованности синхронизации с поисковой системой. Таким образом, хранение тегов становится менее важным.