Как добавить данные в JSON колонку в БД без SELECT'a?

Question

[Павел]

Всем привет. Есть таблица с колонкой data с типом jsonb. Там хранится, например, массив messages с сообщениями в диалоге. Возможно ли добавлять новое сообщение в массив data->messages без необходимости сначала вытащить весь диалог, добавить в конец массива новое сообщение и обратно записать в БД? Или это не реализуемо самой СУБД?

СУБД PostgreSQL

Answer 1

[Александр Талалаев]

Раз возникла такая проблема, это повод задуматься о правильности выбора структуры БД, конкретно о том стоит ли так хранить messages. Но в любом случае PostgreSQL изначально по задумке сделан так что обновление поля это всегда его полная перезапись, таким образом вам в любом случае нужно прочитать оттуда чтобы не потерять предыдущие записи.
Ну и все же есть рекомендации по использованию этого типа JSON в постгресе, вы уверены что ваша реализация следует им?

Comments

[Павел]

Окей. Не лучший вариант, что бы хранить большие документы. "Раз возникла такая проблема" - ну проблема пока не возникла, я просто предполагаю, что обмен сообщениями (пусть это и не мгновенные сообщения, а скорее можно сравнить с перепиской по эл.почте) превратится в кучу запросов, когда, что бы добавить одну строчку, нужно сначала достать 200. А что можете посоветовать? Нужно, грубо говоря, хранить документы с переписками. В них будут идентификаторы юзеров и массив сообщений с указанием даты и отправителя в каждом. MongoDB подошла бы?

[Александр Талалаев]

Павел, а зачем придумывать, почему не использовать стандартную реляционную модель? Есть нет какого-нибудь специфического случая, я думаю городить сверх оптимизации не нужно, просто создать полноценную схему для вашего чата. Тм более это такая вещь что может потребовать неизвестно какого функционала в будущем, и будет удобно иметь изначально хорошую схему связанную с пользователем.
А так конечно можно и nosql решением пользоваться, хранить тупо все, но снова таки, вопрос упирается в стратегию развития проекта, что будет потом, какие проблемы решит, какие создаст. Везде свои плюсы и минусы.
Лично я склоняюсь к обычному подходу с реляционной БД для сообщений, как более гибкой и простой в плане возникновении потребности в написании доп логики(она уже реализована в СУБД), как было бы с key:value подходом, он вот хорош для всякого кеширования например.