数据库设计:私人聊天,群聊和电子邮件

时间:2011-06-08 00:00:29

标签: mysql database database-design

Facebook用户之间的沟通似乎存储在一个长期的“对话”中。因此,发送的电子邮件和所交换的私人聊天消息似乎都是长时间持续对话的一部分。

我认为这个实现适用于用户(至少对我而言)。我假设这部分的表格设计可以这样实现:

TABLE: message
 - message_id
 - timestamp
 - from_user_id
 - to_user_id
 - message

如果我想支持群聊怎么办?我会做这样的事情:

TABLE: message
 - message_id
 - timestamp
 - from_user_id
 - message

TABLE: message_recipient

 - message_recipient_id
 - message_id
 - to_user_id

我认为它会起作用。但是,我想知道如果我在一次长谈话中显示用户曾经向任何人发送的每一件事情,对用户是否有意义。它可能不会。想象一下与人A的对话与人A,B,C,D的混合与人E的对话混合等等......

关于什么是可用的概念实施的任何建议?

2 个答案:

答案 0 :(得分:7)

我认为邮件应该是一个实体,无论平台或发件人/收件人,都有idmessagetimestamp字段和消息关系表 - 就像您建议的那样 - 使用idmessage_idfrom_idto_id。 然后,如果您向用户对话显示单个用户,则可以显示它们之间的每条消息。 对于群组聊天,您应该有一个包含idtitletimestamp的表,其中包含群聊主记录,另一个表包含属于该群聊的用户,使用idgroup_chat_iduser_id字段。

我的意见以及如何实施它。

编辑:也许在邮件实体本身上设置from_id是有意义的,因为邮件必须具有单一的发件人ID。

答案 1 :(得分:1)

您还可以按主题对邮件进行分组。 您添加主题表。您添加绑定到主题的收件人表。消息也将与主题相关联。

您可以通过查看哪个主题在其收件人中拥有这两个用户,以编程方式限制两个用户之间的主题。 您还可以通过为消息提供type属性来分隔消息。例如,类型0将是收件箱消息,类型1将是聊天消息,依此类推。

如果我想在一个主题中拥有任意数量的收件人,我会避免使用from_id / to_id组合。

相关问题