Question

我正在寻找向系统内多个用户实施消息传递的最佳解决方案（Facebook风格）。

我提出了以下想法：每条消息属于Message_Chain，Message_status表中列出了user-sender和users-receivers。但是，当系统中有数百万条消息时，我担心这种模式的使用效率不高。

有人能建议解决当前问题吗？或解释为什么我的解决方案会没问题？

CREATE  TABLE `message` (
  `msg_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `msg_text` TEXT NOT NULL ,
  `msg_date` DATETIME NOT NULL ,
  PRIMARY KEY (`msg_id`) );

CREATE  TABLE `message_chain` (
  `msgc_id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `msgc_topic` VARCHAR(255) NULL ,
  PRIMARY KEY (`msgc_id`) );

CREATE  TABLE `message_status` (
  `msgsta_msg_id` BIGINT UNSIGNED NOT NULL ,
  `msgsta_usr_id` INT UNSIGNED NOT NULL ,
  `msgsta_msgc_id` INT UNSIGNED NOT NULL ,
  `msgsta_is_sender` TINYINT(1)  NULL ,
  `msgsta_is_read` TINYINT(1)  NULL DEFAULT NULL ,
  `msgsta_is_deleted` TINYINT(1)  NULL ,
  PRIMARY KEY (`msgsta_msg_id`, `msgsta_usr_id`);

Answer 1

只要没有相同邮件的收件人太多，架构就可以正常工作。我不知道你怎么能把它变得更小或更有效率。

我能看到的唯一性能问题是，如果您想进行广播，即将相同的消息发送给大型组，或者说系统上的每个用户。发送这样的消息将非常缓慢（在那里，做到了）。在这种情况下，我会懒惰地跟踪这些全局消息的状态，即只有在打开消息后才为单个用户创建状态行。但是如果你没有计划这样的功能，我现在就说要忽略这个问题。

Answer 2

我的解决方案是通过使用更多编程来确定哪些消息发送给谁来避免海量数据存储。

例如，如果要向系统的所有用户发送消息，请在usr_id列中放置“”，然后以编程方式获取usr_id = current_usr_id OR'”。然后你可以做各种过滤器，并提出自己的语法来创建没有数据库存储的messager_user列表。

似乎是处理/存储之间的权衡......

向多个用户发送消息的数据库模式

2 个答案: