Схема базы данных для обмена сообщениями с несколькими пользователями

Я ищу лучшее решение для обмена сообщениями с несколькими пользователями в системе (в стиле 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`);

mysql facebook database schema messages
person Websirnik    schedule 23.11.2010    source источник
comment
Однако я боюсь, что эта схема не очень эффективна для использования, когда в системе миллионы сообщений... Я думаю, что вы должны сначала достичь этого предела, прежде чем слишком беспокоиться о некоторых деталях, преждевременная оптимизация - корень всех пороки :)   -  person Jack    schedule 23.11.2010
comment
Не согласен :) Зрелое планирование = отсутствие головной боли в будущем   -  person Websirnik    schedule 23.11.2010

Ответы (2)


arrow_upward
0
arrow_downward

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

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

person Gintautas Miliauskas    schedule 23.11.2010

arrow_upward
0
arrow_downward

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

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

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

person MikeMurko    schedule 11.12.2010
comment
Это на самом деле не отвечает на вопрос. Если у вас есть другой вопрос, вы можете задать его, нажав Задать вопрос. Вы также можете добавить вознаграждение, чтобы привлечь больше внимания к этому вопросу. – Из обзора - person Ewald Hofman; 29.12.2015
comment
@EwaldHofman, вопрос: может ли кто-нибудь предложить какое-либо другое решение текущей проблемы? - person MikeMurko; 03.01.2016