私信设计

table user:
- id (pk)
- name

table conversation (one entry per "chat/messaging" session)
- id (pk)
- started_by_user_id
- started_ts

table conversation_participant (keeps track of all recipients)
- id (pk)
- conversation_id
- user_id (refers to user.id)

table message
- id
- conversation_id (refers to conversation.id)
- sender (refers to user.id)
- msg

我不会说你在帖子中提出的实现一定是糟糕的。当然,它不是最简洁或最快的,但在我看来,它对人类来说是最容易理解的。此外,删除逻辑应该不难封装。

我可能建议的一个解决方案是使用一个存储每条消息的表,其中包含发件人ID的字段和另一个收件人ID列表的字段。当然,问题在于决定如何使用标准数据库类型之一表示ID列表,因为通常没有数组/向量/列表类型。我建议您使用VARBINARY(max)类型(如果可用),将其视为位向量(例如,每个收件人ID 4个字节)。然后,您可以创建几个函数来对数组/列表进行非常简单的逐位编码/解码。

否则,这是有道理的。..但我不明白为什么删除逻辑会很尴尬。您可以通过以下两种方式之一处理它:

1. 用户删除后:如果没有其他收件人,请删除。

例如。:

DELETE FROM pm_messages
RIGHT JOIN pm_recipients ON pm_messages.id = pm_recipients.pm_messages_id

还有一个用例需要考虑(我知道我的用户想要这个)。..他们都想要一个“已发送的项目”。可以这么说,在清理房子之前,你可能想考虑一下这个用例。

让我感到困扰的是这些信息 收件人已删除 导致一些尴尬的信息 删除逻辑。

创建一个触发器来为您完成此操作。你的应用程序代码需要做的就是担心将你的“已删除”列设置为true,并在所有人都将消息标记为已删除时,让UPDATE触发器取消整个交易。

当然,接下来你会知道,你的用户会想要取消删除。就我个人而言,我永远不会从数据库中删除消息,只会对用户隐藏它。

(评论太长了)

Tehvans方法涉及存储特定对话的参与者列表,而在您的方法中,参与者是按每条消息存储的。我预计这样做的原因是允许删除和读取标记,问题是——为什么会这样?