Как организовать таблицы базы данных для системы обмена сообщениями, когда сообщения могут транслироваться? - PullRequest
Новая
       1

Как организовать таблицы базы данных для системы обмена сообщениями, когда сообщения могут транслироваться?

3 голосов
/ 26 мая 2011

Представьте себе веб-сайт электронной коммерции, где пользователи могут создавать свои собственные магазины.
Я разрабатываю внутреннюю систему обмена сообщениями для такого веб-сайта, и в настоящее время я сомневаюсь в том, как реализовать ее в базе данных.

Должны поддерживаться следующие сценарии:

  • [u => u] пользователь может отправить сообщение другому пользователю;
  • [u => s] пользователь может отправить сообщение в магазин;
  • [s => u] store может отправить сообщение впользователь;
  • [s => uu] store может отправить сообщение всем своим покупателям.

Если бы у меня была только простая таблица MessagesИ магазин хотел передать сообщение 10 000 пользователей, мне нужно было бы вставить 10 000 подобных записей одновременно.

Другой подход заключается в разделении PersonalMessages и BroadcastMessages отдельно и введении BroadcastMessageReceivers таблицы «отображения».Однако такой подход усложняет работу с отдельными сообщениями, такими как удаление, отображение входящих и исходящих сообщений и т. Д.

Есть ли рекомендуемый вариант, учитывая, что я использую Entity Framework и MS SQL 2008?

Ответы [ 2 ]

3 голосов
/ 26 мая 2011

Если вы хотите, чтобы каждый пользователь мог управлять содержимым своей папки входящих сообщений, вы должны обрабатывать широковещательное сообщение как набор отдельных сообщений (или некоторые отношения M: N) - каждый пользователь должен иметь свою собственную запись, поэтому, если он удаляет сообщениеиз папки «Входящие» другие пользователи не будут затронуты.Реализация зависит от того, как вы хотите обрабатывать широковещательную рассылку. Нужно ли работать с самим широковещательным сообщением?Тогда вам нужен отдельный тип сущности.

Если вы хотите использовать Entity Framework, убедитесь, что у вас есть хранимые процедуры для вещания.Хранимая процедура примет сообщение, отправителя и хранилище и создаст записи для всех целевых пользователей.Делать это напрямую через EF будет ужасно медленно.

1 голос
/ 26 мая 2011

Я сделаю это следующим образом, 

Message Table
   ID
   FromUserID int FK
   ToUserID nullable int FK
   Title
   MessageBody

Здесь, когда ToUserID равен нулю, тогда сообщение предназначено для всех.В противном случае это личное для ToUserID.Запросы также просты,

Чтобы отобразить все сообщения для одного пользователя и пользователей, которым вы транслируете, 

Context.Messages.Where(
       x=> x.ToUserID == null ||
           x.ToUserID == currentUserID
    );

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

...