Postgresql 如何使用当前的模式设计有效地设计消息传递系统？

我正在为消息传递应用程序设置数据库架构。我有一个messages表，其中存储了主题、正文、创建者（发送消息的人的id）、状态（已发送、草稿、未读）消息和其他信息，然后我还有一个sent表来跟踪messageid（来自messages表的消息id）和senderid（来自user表的发送者id）还有一个收件箱表，用于跟踪messageid和receiverid（用户表中接收方的id）。我希望实现以下目标：

• 每次我插入messages表（发布消息）时，我都会以编程方式将发送方的状态设置为“已发送”，接收方的状态设置为“未读”，这有意义吗
• 考虑到前端，收件箱中的每封邮件在默认情况下都是未读的，因此当它被单击时，它会变为已读，这有意义吗
• 在收件箱表中设置另一个状态如何？当我插入收件人的收件箱表时，默认状态为“未读”，在收件人的消息表中设置为“已发送”
• 如何有效地跟踪parentmessageid并使用它启动一个线程作为对初始消息的回复

这就是messages表现在的外观

CREATE TABLE messages (
  id SERIAL PRIMARY KEY NOT NULL,
  subject CHARACTER VARYING(255) NOT NULL,
  message CHARACTER VARYING(500) NOT NULL,
  parentmessageid INTEGER NULL,
  creator INTEGER NOT NULL,
  FOREIGN KEY (parentmessageid) references messages (id) on delete CASCADE,
  FOREIGN KEY (creator) references users (id) on DELETE CASCADE,
  status CHARACTER VARYING(50) NOT NULL,
  createdon TIMESTAMP WITH TIME ZONE DEFAULT now()
)`;

收件箱表：

CREATE TABLE inbox (
  id SERIAL PRIMARY KEY NOT NULL,
  messageid INTEGER NOT NULL,
  receiverid INTEGER NOT NULL,
  FOREIGN KEY (messageid) REFERENCES messages (id) on DELETE CASCADE,
  FOREIGN KEY (receiverid) REFERENCES users (id) on DELETE CASCADE,
  createdon TIMESTAMP WITH TIME ZONE DEFAULT now()
)`;

已发送的表：

CREATE TABLE sent (
  id SERIAL PRIMARY KEY NOT NULL,
  messageid INTEGER NOT NULL,
  senderid INTEGER NOT NULL,
  FOREIGN KEY (messageid) REFERENCES messages (id) on DELETE CASCADE,
  FOREIGN KEY (senderid) REFERENCES users (id) on DELETE CASCADE,
  createdon TIMESTAMP WITH TIME ZONE DEFAULT now()
)`;

注：我在stackoverflow上看到了一些关于类似问题的答案，但我只是好奇我目前的设计会如何运作

---

我不认为这个问题需要搁置。StackOverflow是一个由专业人士组成的社区，我的问题是想看看其他更好的方法来实现同样的目标。我们很欣赏这些意见，因为我们可以从任何回答这个问题的人那里学习。目前，只有一个人回答了这个问题，那么我们该如何学习呢？

这在很大程度上取决于您想要实现什么，但您的数据模型对我来说太复杂了

我只需要一个

消息

和一个

用户

表。每封邮件都有一个发件人和一个收件人（通过外键链接）、一个

发件人状态

（草稿/已发送/…）和一个

收件人状态

（未读/已读/已删除）

---

收件箱和发件箱不必是表，它们是通过查询

邮件
表来确定的。
“每次我插入邮件表（发布邮件）时，我都以编程方式将发件人的状态设置为“已发送”是否有意义”否。保存草稿如何？发送仍在进行中？状态应在另一个表中。然后，您可以轻松查询具有此状态或该状态的邮件，而无需冒打字错误的风险，并将重复信息占用的磁盘空间乘以。我支持您在问题中所做的努力，但我投票关闭，因为这是基于意见的，也是broad@Cid有道理，但如何从后端实现草稿状态？这一点更为广泛：添加保存消息的按钮？这是另一种看待它的方式。竖起大拇指