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

В повечето случаи бих използвал нормализирана схема с таблица option_tag прилагане на връзката много към много между таблиците option и tag . Референтна реализация тук:

• Как да внедрим връзка много към много в PostgreSQL?

Може да не е най-бързата опция във всяко отношение, но предлага пълната гама от функционалности на DB, включително референтна цялост, ограничения, пълната гама от типове данни, всички опции за индексиране и евтини актуализации.

За пълнота добавете към списъка си с опции:

• hstore (добър вариант)
• xml по-подробен и по-сложен от всеки hstore или jsonb , така че бих го използвал само когато работя с XML.
• "низ от стойности, разделени със запетая" (много проста, най-вече лоша опция)
• EAV (Entity-Attribute-Value) или „двойки име-стойност“ (предимно лоша опция)
  Подробности под този свързан въпрос на dba.SE:
  • Има ли име за тази структура на база данни?

Ако списъкът е само за показване и рядко се актуализира, бих помислил за обикновен масив, който обикновено е по-малък и се представя по-добре за това от останалите.

Прочетете запис в блога от Джош Беркус @a_horse, свързан към в неговия коментар. Но имайте предвид, че се фокусира върху избрани случаи на четене. Джош признава:

И това е мястото, където нормализираният подход печели много, особено когато променяте много единични тагове при едновременно натоварване.

jsonb е добър вариант само ако все пак ще работите с JSON и можете да съхранявате и извличате JSON „както е“.