Question

在我的由MySQL数据库支持的Web应用程序中，我想提供一个消息系统，其中消息被分组到多个用户之间的对话中，但我仍然坚持设计满足我的一些需求的表结构：

多个用户可以参与一个对话
用户可以加入，阅读，离开和删除对话
收件箱视图应尽可能少生成查询

现在，可以通过使用联结表来解决多对多关系的第一个要求。但事实证明，在为收件箱视图编写选择查询时会产生很多问题。

第二项要求也证明是一项挑战。如果用户离开了对话，则他仍然可以阅读旧消息。不应与离开的用户共享对话中剩余用户之间的新消息。我首先考虑使用树状结构进行对话。每次用户加入或离开对话时，都会创建一个新会话，并引用父对话，并创建与联结表中其余参与者的新关系。

第三个要求似乎也不是微不足道的。收件箱视图应显示与特定用户作为参与者的对话列表。此外，还应为每个对话显示其他信息：所有当前参与者的姓名，对话的最后回复以及该回复的作者。将收件箱视图视为一个消息列表，其中包含有关其所属对话的其他信息。

我目前的做法如下：

CREATE TABLE `conversation` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `parentId` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `parentId` (`parentId`),
  CONSTRAINT `conversation_ibfk_1` FOREIGN KEY (`parentId`) REFERENCES `conversation` (`id`)
);
CREATE TABLE `participant` (
  `userId` int(11) unsigned NOT NULL,
  `conversationId` int(11) unsigned NOT NULL,
  `readAt` datetime DEFAULT NULL,
  PRIMARY KEY (`userId`,`conversationId`),
  KEY `conversationId` (`conversationId`),
  CONSTRAINT `participant_ibfk_2` FOREIGN KEY (`conversationId`) REFERENCES `conversation` (`id`),
  CONSTRAINT `participant_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `user` (`id`)
);
CREATE TABLE `reply` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `conversationId` int(11) unsigned NOT NULL,
  `userId` int(11) unsigned NOT NULL,
  `text` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY `conversationId` (`conversationId`),
  KEY `userId` (`userId`),
  CONSTRAINT `reply_ibfk_2` FOREIGN KEY (`userId`) REFERENCES `user` (`id`),
  CONSTRAINT `reply_ibfk_1` FOREIGN KEY (`conversationId`) REFERENCES `conversation` (`id`)
);
CREATE TABLE `user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
);

我在这里遇到了障碍，无法找到满足我所有需求的解决方案。也许有人可以就如何处理这个数据库设计给我一些建议。

Answer 1

用户活动

我仍然会建立一个联结表，但是在元组上有索引。

USER_CONV   
---------------
id_user 
id_conversation
active_flag
begin_flag              - flag indicating if id_first_reply == id_first_visible_reply
id_first_reply          - first reply in the conversation
id_first_visible_reply  - first visible for a given user
id_last_reply           - last visible for a given user, user if active_flag = false, otherwise NULL

index (id_user, id_conversation, active_flag) 


USER_REPLY
---------------
id_user
id_conversaion
id_reply

index (id_user, id_conversation, id_reply)

USER_CONV应该可以减少创建收件箱的麻烦。您仍需要使用USER_REPLY加入，然后使用REPLY加入。

收件箱

如果你想快速创建，那么创建一种CACHED_INBOX，以及一个带有MOST_RECENT_USER_ACTIVITY的表。 CACHED_INBOX表将包含您不需要进行任何连接以获取相关数据的所有收件箱数据，但您只需要使用MOST_RECENT_USER_ACTIVITY中的数据执行UNION。 MOST_RECENT_USER_ACTIVITY应该非常小（快速工作），CACHED_INBOX将是“静态的”。然后每天一次，或者当服务器不太可能被使用时每隔几天做一次批量CACHED_INBOX更新。它将起作用，除非您的用户决定永远保持对话。

优化

当然，您需要使用一些解释，以查看查询优化器如何使用索引（如果它完全使用它）。 Mybe你需要一个类似ACTIVE_CONVERSATIONS的表，它不会有任何索引，这会对性能产生一些影响。但是，您将对USER_CONV进行一些批量更新，这将有更广泛的索引。您必须尝试一下，看看您对用户行为的期望，应该是架构驱动程序之一。

注意：关于索引，有一个很好的网站致力于索引use-the-index-luke.com的主题

对话消息系统的SQL表设计

1 个答案:

用户活动

收件箱

优化