Question

我正在设计用于聊天对话的表格。代替创建2表：对话和消息。我只设计了一张表：对话并使用JSONB字段作为Message。

你们检查这张照片：

此数据库结构解决方案是好是坏？如果情况不好，我还有其他解决方案吗？

Answer 1

我强烈建议您标准化表结构。

参与者应进入id_conversation和id_user列的单独表中。搜索和更新比使用（json）数组更好。

与messages相同。为什么不将它们存储到包含列id_conversation，timestamp，id_user，message_text的单独表中？它也将更好地设计用于搜索和更新。而且它使您的对话表更小。

附加：该participants列的用途是什么？如果每个对话都有消息，您可以轻松地向表询问所有向对话提交了消息的用户，例如

SELECT DISTINCT id_user FROM messages WHERE id_conversation = 42

修改：

原则上：1M数据集很多，但不是一个巨大的表。具有良好表设计的Postgres应该不会有任何问题。但是我认为一次对话中的消息要少得多，因此您可以做很多事情来进行过滤和索引编制。

1。我强烈建议您为表格考虑一些聪明的索引，这应该可以使搜索真正快速。也许在邮件时间戳上建立索引可能会有所帮助，而在转化ID上建立索引可能会有所帮助：

CREATE INDEX idx_messages_timestamp
ON messages (timestamp);

CREATE INDEX idx_messages_conversations
ON messages (id_conversation);

如果您希望获取较新的消息，以DESC顺序（... ON messages(... DESC)）创建索引可能会有所帮助

2。对于非常大的表（我的意思是非常大的表），分区可能会有所帮助。这将根据特定条件在内部对表进行拆分-可能按时间戳（例如每月或每年）进行。因此，如果您主要获取一些新数据，则较旧的数据将在内部存储在单独的表中。因此，查询仅在所请求的较小表的行上。