Хорошо ли хранить сообщения чата в json field django?

Question

В моем приложении django мне нужно приложение для разговора между пользователем и автором, для которого я планирую сделать модель как -

class AuthorContact(models.Model):
    messages = JSONField(default=dict)
    user = models.ForeginKey(User,related_name="contact_user",on_delete=models.CASCADE)
    author = models.ForeginKey(Author, related_name="contact_manager",on_delete=models.CASCADE)

, что я планирую хранить сообщения как -

{
'1':{'sender':'user','date':'02/12/2019','message':'Hi I read your book, it\'s amazing !'},
 '2':{'sender':'author','date':'0312/2019','message':'Thank you, it\'s my pleasure.}'
}

Если сообщение CharField, мне нужно создать объект для каждого сообщения с пользователем и автором.

Я делаю это, поэтому мне не нужно создавать объект для каждого сообщения, и его легкоБД, чтобы найти разговор между конкретным пользователем и автором.

Мои вопросы -

Это хорошая практика?

Какой максимальный размер позволяет PostgreSQLхранить в этом поле json?

Является ли этот трюк полезным, вместо того, чтобы создавать объект для каждого сообщения и затем искать определенный чат?

Есть ли какой-нибудь другой способ лучше?

Answer 1

Я бы сказал, что это решение не идеально.

Максимальный размер типа json в postgres не ограничен, но я не думаю, что вы хотите использовать это направление с большим json dictсвалка.Когда это поле увеличивается, время для его извлечения будет только расти.В конце концов вам придется как-то отфильтровать что-то на стороне API, иначе вам придется отправить весь текстовый блоб по проводам вашему пользователю.

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

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

Это из документации postgres по типам JSON

8.14.2.Эффективное проектирование документов JSON

Представление данных в виде JSON может быть значительно более гибким, чем традиционная реляционная модель данных, что является привлекательным в средах, где требования изменчивы.Оба подхода вполне могут сосуществовать и дополнять друг друга в одном приложении.Однако даже для приложений, где требуется максимальная гибкость, все же рекомендуется, чтобы документы JSON имели несколько фиксированную структуру.Структура, как правило, не применяется (хотя принудительное применение некоторых бизнес-правил возможно), но наличие предсказуемой структуры облегчает написание запросов, которые с пользой суммируют набор «документов» (данных) в таблице.

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

Кроме того, при получении сообщений вы сможете фильтроватьсколько и сколько лет сообщений, которые вы хотите получить.(ГДЕ create_time> 'гггг-мм-дд' ORDER BY id DESC LIMIT 20) и тому подобное.Некоторые из тех же эффектов могут быть достигнуты с помощью операторов JSON postgres, но скорость, естественно, никогда не будет сопоставимой.

В принципе, существует длинный список причин, по которым реляционные базы данных превосходят текстовые объекты, которые я не использую.Я думаю, что вы хотите игнорировать.

Отредактировано из уроков в комментариях ниже от му слишком короткий