Проектирование баз данных для почтовой системы обмена сообщениями
Я хочу заставить почтовую систему обмена сообщениями как Gmail иметь. Я хотел бы иметь следующую опцию: Звездообразный, Мусор, Спам, Проект, Чтение, Непрочитанное. Прямо сейчас я имею ниже следующей структуры в моей базе данных:
CREATE TABLE [MyInbox](
[InboxID] [int] IDENTITY(1,1) NOT NULL,
[FromUserID] [int] NOT NULL,
[ToUserID] [int] NOT NULL,
[Created] [datetime] NOT NULL,
[Subject] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[Body] [nvarchar](max) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[IsRead] [bit] NOT NULL,
[IsReceived] [bit] NOT NULL,
[IsSent] [bit] NOT NULL,
[IsStar] [bit] NOT NULL CONSTRAINT [DF_MyInbox_IsStarred] DEFAULT ((0)),
[IsTrash] [bit] NOT NULL CONSTRAINT [DF_MyInbox_IsTrashed] DEFAULT ((0)),
[IsDraft] [bit] NOT NULL CONSTRAINT [DF_MyInbox_Isdrafted] DEFAULT ((0))
) ON [PRIMARY]
Но я сталкиваюсь с некоторыми проблемами с вышеупомянутой структурой. Прямо сейчас, если пользователь A отправляет msessage пользователю B, я храню строку в этой таблице, Но если пользователь B удаляет, которые обмениваются сообщениями, это получает удаленного пользователя кадра отправленное сообщение также. Это неправильно, я хочу точно, как нормальная почтовая система обмена сообщениями делает. Если A удаляет сообщение из его отправленного объекта затем B, не должен быть удален из его ящика входящих сообщений. Я думаю на другой проблеме здесь, которая прибудет, предполагают пользователя отправленный почта 500 пользователям сразу так согласно моему дизайну, у меня будет 500 строк с дублирующимися телами т.е. не памятью efficent способ сохранить его. Могли Вы парни, помогите мне в makeing дизайн для системы обмена сообщениями?
6 ответов
Для этого вам нужно разделить вашу таблицу. У вас может быть следующая схема и структура
CREATE TABLE [Users]
(
[UserID] INT ,
[UserName] NVARCHAR(50) ,
[FirstName] NVARCHAR(50) ,
[LastName] NVARCHAR(50)
)
CREATE TABLE [Messages]
(
[MessageID] INT ,
[Subject] NVARCHAR(MAX) ,
[Body] NVARCHAR(MAX) ,
[Date] DATETIME,
[AuthorID] INT,
)
CREATE TABLE [MessagePlaceHolders]
(
[PlaceHolderID] INT ,
[PlaceHolder] NVARCHAR(255)--For example: InBox, SentItems, Draft, Trash, Spam
)
CREATE TABLE [Users_Messages_Mapped]
(
[MessageID] INT ,
[UserID] INT ,
[PlaceHolderID] INT,
[IsRead] BIT ,
[IsStarred] BIT
)
В таблице пользователей вы можете иметь пользователей. «Сообщения» обозначает таблицу для сообщений. «MessagePlaceHolders» обозначает таблицу для заполнителей для сообщений. Заполнителями могут быть входящие, отправленный элемент, черновик, спам или корзина. «Users_Messages_Mapped» обозначает таблицу сопоставления для пользователей и сообщений. «UserID» и «PlaceHolderID» являются внешними ключами. «IsRead» и «IsStarred» обозначают то, что обозначают их имена. Если для определенного идентификатора сообщения в таблице «Users_Messages_Mapped» не найдена запись, эта запись будет удалена из таблицы Messages, поскольку она нам больше не нужна.
Сообщение может находиться только в одной папке за раз, поэтому вам нужна таблица папок (содержащая папки «Корзина», «Входящие», «Архив» и т. Д.) И внешний ключ от сообщений к папкам. Для меток у вас есть отношение «многие ко многим», поэтому вам понадобится таблица меток, а также таблица ссылок (messages_labels). Для звездочки подойдет простой битовый столбец, то же самое для «непрочитанного».
Если вы работаете с документами, я предлагаю взглянуть на CouchDB . Он не имеет схемы, что означает, что подобные проблемы исчезают.
Давайте посмотрим на пример: A отправляет сообщение B, и оно удаляется B.
У вас будет единственный экземпляр документа с получателями , указанными как атрибут электронная почта. Когда пользователи удаляют сообщения, вы либо удаляете их из списка получателей, либо добавляете их в список deleted_by или как хотите.
Это совершенно другой подход к данным, чем тот, к которому вы привыкли, но может оказаться очень полезным, если вы потратите время на его обдумывание.
На вашем месте я бы установил два флага: один для отправителя, а другой - для получателя, если оба флага верны, тогда сообщение должно быть удалено из базы данных, в противном случае сохранить это в базе данных, но скрыть от того, кто удалил Это.
Сделайте то же самое с мусором. Вы можете запустить cron или вручную проверить, удаляют ли отправитель и получатель сообщение, а затем удалите его из базы данных.
Вы можете создать таблицу MessageContacts, которая соединяет каждое сообщение с людьми, у которых оно есть в почтовых ящиках. Когда пользователь удаляет сообщение, строка удаляется из MessageContacts, но оригинальное сообщение сохраняется.
Вы можете сделать это... но я не советую. Если это не академическое задание, заданное вашим преподавателем, то разработка собственной системы обмена сообщениями - пустая трата времени. Если это домашнее задание, то вы должны сказать об этом. Если нет, то займитесь чем-нибудь более полезным.
Я думаю, вам нужно еще немного разложить схему. Храните электронные письма отдельно и сопоставляйте почтовые ящики с сообщениями, которые они содержат.