比较内部消息传递的两种数据库设计

以下哪种数据库设计更适合内部消息系统。

三张表：

MessageThread(models.Model):
    - subject
    - timestamp
    - creator

Message(models.Model):
    - thread (pk)
    - content
    - timestamp
    - sender

MessageRecipient
    - message_id (pk)
    - recipient (pk)
    - status (read, unread, deleted)

两张表：

Message
    - thread_id
    - subject
    - content
    - timestamp
    - sender (fk)

MessageRecipient
    - message_id (fk)
    - recipient (fk)
    - status (read, unread, deleted)

其中一种相对于另一种有什么优势？谢谢。

第一名的优点

第一个模式遵循更好的规范化规则，因此在大多数情况下可能更好。

有一个thread_id，这基本上是一个自然键，这不是另一个表的 FK 可能是自找麻烦。当你想要它是唯一的时候，要强制它是唯一的，当你想要它是相同的时候，要强制它是相同的，这将是非常困难的。出于这个原因，我鼓励第一个建议的模式。

第二个的优点

您的第二个架构允许更改线程中每条消息的主题。如果这是您想要的功能，则不能使用第一个选项，因为您已经编写了它（但请参见下文）。

其他选项

Message
    - id
    - parent (fk to Message.id)
    - subject
    - content
    - timestamp
    - sender (fk)

MessageRecipient
    - message_id (fk)
    - recipient (fk)
    - status (read, unread, deleted)

而不是有一个thread_id概念，你可以有一个parent概念。那么每条回复都会指向原始消息的记录。这允许线程化，而无需“线程”表。这样做的另一个可能的优点是它允许线程树以及。简而言之，您可以通过这种方式表示消息和回复之间更复杂的关系。如果你不关心这一点，那么这不会对你的申请有好处。

如果您不关心我刚才提到的线程优势，我可能会推荐两种模式的混合：

MessageThread(models.Model):
    - id

Message(models.Model):
    - thread (pk)
    - subject
    - content
    - timestamp
    - sender

MessageRecipient
    - message_id (pk)
    - recipient (pk)
    - status (read, unread, deleted)

这与第一个架构类似，只是我将“主题”列从MessageThread to the Message表，以允许主题随着线程的进展而改变...我只是使用 MessageThread 表作为 Message 中使用的线程 ID 的约束（这克服了我在答案开头提到的限制）。您可能还想将其他元数据包含在 MessageThread 表中，但我会将其留给您和您的应用程序。