В чем разница между тип поля и тип поля[]

Например, text и text[]

Perederiy
Например, text и text[]

По идее text[] - это массив типа text :-)
Хотя разница сомнительная.

mad_nazgul,

Скалярное значение и массив, строгая типизация.

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

А почему возник такой вопрос?

vyegorov,
если предполагается в поле хранить (и работать с ним) массив, то какой тип лучше

PS
Вдогонку общий вопрос. Меня убеждают, что использовать массивы - это здорово ( в базе два десятка таблиц и в каждой много полей с массивами в полях). Я признаться в своих проектах массивы вообще не использовал. Кто имеет опыт с массивами - поделитесь: плюсы и минусы

Perederiy
vyegorov, если предполагается в поле хранить (и работать с ним) массив, то какой тип лучше PS Вдогонку общий вопрос. Меня убеждают, что использовать массивы - это здорово ( в базе два десятка таблиц и в каждой много полей с массивами в полях). Я признаться в своих проектах массивы вообще не использовал. Кто имеет опыт с массивами - поделитесь: плюсы и минусы

Ну вообще-то массивы это уход от реляционной модели.
По большому это "синтаксический сахар".
Т.е. вместо нормализации БД, мы можем ввести в какую-нибудь таблицу массив.
Плюсы - простота
Минусы - отход от реляционной модели данных.

И раньше, по моему до 8 версии, массивы тормозили.
Сейчас вроде бы нормально.

Perederiy
если предполагается в поле хранить (и работать с ним) массив, то какой тип лучше

Реляционные СУБД строго типизированы. Если нужны временные метки, используйте timestamptz, если числа — соответствующий числовой тип. И массив строить на основе соответствующего типа. Если вы хотите хранить дома, километры и литры в одном поле типа text[], то у вас будут проблемы, даже если вы думаете (или вас убеждают) в обратном!

Perederiy
Меня убеждают, что использовать массивы - это здорово ( в базе два десятка таблиц и в каждой много полей с массивами в полях). Я признаться в своих проектах массивы вообще не использовал. Кто имеет опыт с массивами - поделитесь: плюсы и минусы

Думаю, что вас склоняют к No-SQL (key-value). Для этого будет лучше использовать JSONB тип.

Массивы очень удобны для специфических задач. Но в целом для дизайна я предпочитаю реляционную модель. Она и гибка (для построения запросов), и строга (типы данных и ограничения целостности) одновременно.

mad_nazgul
И раньше, по моему до 8 версии, массивы тормозили. Сейчас вроде бы нормально.

Более того, в работе код, который позволит избежать сворачивания/разворачивания массивов (и других "пакуемых" типов данных) между вызовами функций, прирост в скорости существенный. Я надеюсь, что в 9.5 засунут, хотя бы для массивов и PL/pgSQL.

vyegorov
Думаю, что вас склоняют к No-SQL (key-value). Для этого будет лучше использовать JSONB тип.

для плоского key--value удобнее был hstore (в нём конкатенация была "искаропки")

vyegorov
Массивы очень удобны для специфических задач. Но в целом для дизайна я предпочитаю реляционную модель. Она и гибка (для построения запросов), и строга (типы данных и ограничения целостности) одновременно.

для индексирования как по телу таблицы так и подчинённым записям реляционная модель будет пригодна , если завести такую штуку, как кросс-табличные индексы.

А пока их нет -- суем все нужные подчиненки в массив -- и имеем возможность индексировать хоть GIST-ом + btree_gist. (с поиском по операторам над массивами). Хоть btree по скалярным ф-ям от массивов (применяю). В букваре по gist-ам у Бартунова встречалось. Можно комбинировать -- строгая реляционка, + триггерно поддерживаемые мат-вью (плата -- двойная и более нагрузка на диск).

минусы массивов (и прочей НоСКЛ) -- стандартные средства разработки морд их не поддерживают в плане наличия готовых контролов. надо кодить.

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

Да, я забыл об этом аспекте, GiST с массивами тут рулят.

vyegorov,

минусы массивов

если вы меняете содержимое починенной реляционной записи -- она меняется одна

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

кросс-индексы были бы гораздо предпочтительнее. IOT какой-нибудь, хотя бы -- для handjob-а.