Facebook的数据库设计消息，如应用程序

Question

为内部应用程序设计类似应用程序的Facebook消息。

这是你设计它的方式吗？有什么方法可以改进这个设计吗？谢谢:)）

MESSAGE
Id
Subject
Content
ReadDate -- datetime
DeletedDate -- datetime
CreatedBy -- userid
CreatedOn -- datetime

MESSAGE_COMMENT
Id
MessageId
Content
CreatedBy -- userid
CreatedOn -- datetime

MESSAGE_RECIPIENT
Id
MessageId
Recipient -- UserId 
ReadDate -- datetime
DeletedDate -- datetime

编辑：设计可能缺少某些内容，或者可能不正确，请告诉我。

Answer 1

我认为，这足以发送/接收消息。 更多取决于你想做什么......

Answer 2

首先，从整体设计角度提出一些小建议：

1. 由于您使用Pascal Case作为字段名称，因此您还应该使用它来使Table名称保持一致。所以MESSAGE_COMMENT应该是MessageComment

2. 不要重复使用字段名称“Id”，因为它表示每个表中的内容不同。所以Message中的“Id”应该是“MessageId”，MessageComment中的“Id”应该是MessageCommentId，依此类推

3. 如果该字段是外键，则应包含其指向的字段的名称。因此，“CreatedBy”应为“CreatedByUserId”，“Recipient”应为“RecipientUserId”。请记住，您在为字段命名时越明确，您需要的附加评论和文档就越少，因此对于其他任何人来说，理解预期内容的麻烦就会减少。

现在，就“这是一个适合做X的设计”这个问题而言，你需要提供更多有关你如何设想这个系统工作的细节。看来Message是父，而对它的任何回复都被认为是MessageComments。到目前为止看起来还不错。

我不确定为什么在主Message表中需要“ReadDate”，因为它在MessageRecipient中也存在更准确的级别。除非你想要首先捕获它，但你仍然可以通过查看特定消息的所有收件人从MessageRecipient表中获取它。

最后，您应该考虑不使用“MessageRecipientId”并使用“MessageId”和“RecipientUserId”作为复合主键。这将确保您只能在Message上有一个RecipientUserId，而无需在这两个字段上创建额外的唯一索引。