Схема базы данных для обмена сообщениями с несколькими пользователями - PullRequest
1 голос
/ 23 ноября 2010

Я ищу лучшее решение для реализации обмена сообщениями с несколькими пользователями в системе (в стиле Facebook).

Мне пришла в голову следующая идея: где каждое Сообщение принадлежит Message_Chain, а в таблице Message_status перечислены пользователи-отправители и пользователи-получатели. Однако я боюсь, что эта схема не очень эффективна для использования, когда в системе миллионы сообщений.

Может ли кто-нибудь предложить какое-либо другое решение текущей проблемы? Или объясните, почему мое решение будет в порядке?

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`);

Ответы [ 2 ]

0 голосов
/ 11 декабря 2010

Мое решение состоит в том, чтобы избежать массивного хранения данных, используя больше программ, чтобы определить, какое сообщение кому отправляется.

Например, если вы хотите отправить сообщение всем пользователям системы, вы помещаете " "в столбце usr_id, а затем программным способом вы можете получить все сообщения, где usr_id = current_usr_id ИЛИ ''.Тогда вы можете использовать различные фильтры и придумать собственный синтаксис для создания списков messager_user без хранения базы данных.

Похоже на компромисс между обработкой / хранением ...

0 голосов
/ 23 ноября 2010

Схема должна работать очень хорошо, пока не получено слишком много получателей одного и того же сообщения.Я не понимаю, как вы могли бы сделать его намного меньше или эффективнее.

Единственная проблема с производительностью, которую я вижу, состоит в том, что если вы хотите делать трансляцию, то есть отправлять то же сообщение большой группескажем, каждый пользователь в системе.Отправка такого сообщения будет очень медленной (был там, сделал это).В этом случае я бы лениво отслеживал состояние таких глобальных сообщений, то есть создавал строку статуса для отдельного пользователя только после того, как он открыл сообщение.Но если у вас нет такой функции, я бы сказал, что пока игнорируйте эту проблему.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...