goodwВсем привет, при проектировании архитектуры назрел такой вопрос:

- Есть список абонентов, у каждого из которых есть телефоны (их может быть несколько, но логично предположить, что не очень много — 2-4 максимум (2 мобильных, 1 домашний, 1-2 рабочих и т.д.)

Как это хранить? Что будет быстрее, удобнее и оптимальнее?

1. В связанной таблице phone
id number type person_id

2. В jsonb-поле в основной таблице person:
id name phones

Потребуется поиск по номеру или фрагменту номера. Абонентов может быть и несколько миллионов.
а зачем сразу овноджейсон,б, есть же ещё array-и, например.

но array-и ,например, были бы уместны для поиска , если он [поиск] А. по всему "значению" [элементу] (проверка на && ,&> и т.п.), и Б. велико перекрытие (а не так, что 1 тлфн -- только у одного в среднем, у 2-х -- уже либо ошибка, либо общий служебный/домашний, но в следовых количествах), и поиск ведётся по нескольким признакам -- имя + признак из array-я + ....


т.ч. в вашем случае предыдущий оратор безусловно прав. делайте подчиненную.

goodw,

и почему все мордописцы дрочат на овноджейсона,б ?

для плоской коллекции ключ--значение существует hstore.
т.е. именно коллекция "ключ--значение" [%]
правда -- как extension.
но у него куча плюсов искаропки -- типа конкатенации, дилета и т.п. сахарочка
да и при популяции в рекорд, при наличии в исходной (упакованной) записи полей--массивов он не блажит, как грёбаный жейсон

а индексирование у них, кажецца, одинаково где--то как--то функциональное

goodw,

ps
что касаемо обоснованности -- решать в каждом случае отдельно -- соображений много. кроме возможности составных индексов для сложного поиска И по вхождениям в коллекции (массивы, хештаблицы, json-ы) -- когда все условия в одной табличке и можно придумывать составной индекс -- есть соображения результирующей ширины записи основной таблицы, которая дублируется целиком в новую версию на каждый чих. Т.е. если поиск не поджимает, а апдейты частые -- лучше по возможности декомпозировать по максимуму на атомы (дубль атома дешевле дубля всего компаунда, в котором сменился единственный атом). Опять же индекс перестраивается [читай --необратимо пухнет] только в табличке атомов, но не все индексы -- в табличке компаундов.

т.е. тут соображения балланса.

Проще таки стартовать из по возможности полностью декомпозированого состояния. А уж по мере возникновения проблем с производительностью выборок -- пускаться в дорогие (для версионников) ухудшения [денормализации].