用户消息数据库架构？
这可能是非常主观的，我对此有自己的想法，但是如何构建一个支持用户到用户消息（一对一或一对多）的数据库。
我最初的想法是有一个 MESSAGE 表和 MESSAGE_PARTIES 表
MESSAGE 将包括以下内容 字段： -ID、主题、正文、创建于、父 MSG ID（用于回复）
消息方字段将包括： -ID、消息 ID、发件人 ID、收件人 ID、发送时间
这是合理的逻辑吗？我很想知道更好/更有效的方法是什么。
This is probably very subjective and I have my own thoughts on this, but how would one go about constructing a database that supports user to user messages (one to one or one to many).
My original thought was to have a MESSAGE table and MESSAGE_PARTIES table
MESSAGE would include the following
fields:
-ID, Subject, Body, Created On, Parent MSG ID (for replies)MESSAGE PARTIES fields would include:
-ID, Message ID, Sender ID, Recipient ID, Sent On
Is this sound logic? I'm dying to know what the better/more efficient way is.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您对
MESSAGE PARTIES的看法不太正确。根据您当前的设置，您可以指定多个发件人和多个日期（更准确地说，您可以指定发件人、收件人和日期的多种组合）。这不像我熟悉的任何消息系统，也可能不是您想要的（它也不符合您的描述）。更合适的布局会将发件人和“发送”字段放入
MESSAGE表中，然后仅将ID、Message ID和>。MESSAGE PARTIES表中的收件人 IDYou're not quite right with
MESSAGE PARTIES. Given your current setup, you're able to specify multiple senders and multiple dates (more precisely, you're able to specify multiple combinations of sender, recipient, and date). This is not like any messaging system I'm familiar with, and likely not what you intended (it also doesn't match your description).A more suitable layout would put the sender and "sent on" fields in the
MESSAGEtable, then justID,Message ID, andRecipient IDin theMESSAGE PARTIEStable.