我希望建立一个PM(个人消息)系统,但一直在努力建立一个流动的数据库,链接我的用户'用户的用户。带有消息表的表。
在我的PM系统中,如果您要进入界面,您将看到发件人的头像,发件人的姓名和发件人的邮件。但是,数据库将具有发件人和收件人的名称,邮件的内容以及邮件的发送时间戳。如果已从用户(s')收件箱中删除邮件,数据库也会跟踪。
以下是我已完成的工作:已设置了三个表格('用户'表格,'消息'表格)。 '用户' table包含具有主auto_incremented id的所有注册用户。 '消息' table包含主auto_incremented message_id,包含user_id的行,包含已发送消息的TIMESTAMP的行以及包含message_content的行。我的设置是否正确满足我的要求?
我遇到的问题是发件人的邮件没有与目标收件人链接(事实上,我甚至不知道邮件的去向)。
答案 0 :(得分:1)
当您尝试编写数据库模式时,您必须考虑像实体一样的表(事物)。该表的工作是描述事物的某个部分或某个部分。该描述由属性(列)组成。每行只能描述一件事或一件事(意味着多个表可以代表一件事的各个部分)。这称为database normalization。
因此,在您的情况下,您有3个主要的事情需要关注。
如果您考虑这三件事之间描述的关系,您可以得出结论,您的架构基本上只是一组问题答案的框架,您知道您稍后会问。
例如,如果每个用户都必须有收件箱,并且每个收件箱都可能包含邮件,则Inbox
架构需要有user_id
列,以便您可以识别哪个收件箱属于哪个用户。此外,由于收件箱可能包含一条或多条消息,因此它还必须包含inbox_id
(这将是您的自动增量ID),这将允许您在表中标识唯一的收件箱。显然,Message
架构还需要message_id
列来唯一标识每条消息。架构还需要一个user_id
列,用于标识消息所属的用户(即消息的作者)。
但是,由于Inbox
和Message
之间存在一对多关系,User
和Message
之间存在多对多关系,因此您可以在不产生逻辑不一致的情况下,很容易在同一个表中描述它们之间的关系。这称为3NF or Third Normal Form。
因此,您只需创建第四个表,该表仅描述收件箱及其消息之间的关系。我们暂时将其称为Recipient
表。
Recipient
表需要知道收件箱以及消息以及用户表中哪个用户是此消息的收件人。这意味着你需要3个PK或主键。
inbox_id
message_id
user_id
//这将是收件人的ID 请记住,该列表中的第3个是发送邮件的用户的ID,而不是编写邮件的用户(已由Message
表标识)。
现在,当您想知道哪些邮件位于给定用户的收件箱中时,您只需查询Recipient
并将其加入User
和Message
,就像这样......
SELECT mesage.user_id AS Sender, message.contents, recipient.user_id AS Recipient
FROM recipient, inbox
JOIN message ON recipient.message_id = message.id
WHERE inbox.user_id = ?