Дизайн базы данных для почтового приложения

Question

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

Это то, что я имею до сих пор:

Сообщения (первичный ключ - Id)

• Id (личность)
• SenderId (внешний ключ для Users.Id)
• <данные сообщения>

ReceivedMessages (первичный ключ - MessageId + RecipientId)

• MessageId (внешний ключ к Messages.Id)
• RecipientId (внешний ключ для Users.Id)
• IsRead

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

Но что, если я хочу просмотреть все сообщения, отправленные пользователем, и кому они были отправлены? Для каждого сообщения мне нужно найти все строки ReceivedMessages для этого сообщения и объединить все строки с пользовательской таблицей, а затем каким-то образом объединить все имена (что-то вроде этого: Объединить множество строк в один текст строка ). Может ли это вызывать проблемы с масштабированием или не о чем беспокоиться?

Есть мысли / предложения? Спасибо.

Answer 1

Я не вижу проблем с вашим дизайном, и не буду ожидать и проблем с масштабируемостью при правильной индексации ваших таблиц (если вы не говорите о массовом масштабе, например, gmail, Yahoo mail и т. Д.).

КакЧто касается конкатенации имен получателей, я бы порекомендовал вам сделать это на стороне приложения, а не в SQL, или определить, нужно ли вам вообще это делать (может потребоваться показать список, а не конкатенированную строку).

Answer 2

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

Вы можете сделать это как совокупный запрос, что-то вроде:

SELECT u1.user_name, m.message, GROUP_CONCAT(DISTINCT u2.user_name)
FROM messages m JOIN users u1 ON (m.senderID=u1.user_id)
                JOIN receivedmessages r ON (m.id=r.messageId)
                JOIN users u2 ON (r.RecipientId=u2.user_id)
GROUP BY u1.user_name, m.message;

Но поскольку количество получателей практически не ограничено, вы можете столкнуться с пределом длины строки в GROUP_CONCAT.

Так что, вероятно, лучше сделать неагрегированный выбор и обработать записи для отображения на уровне приложения:

SELECT u1.user_name, m.message, DISTINCT u2.user_name
FROM messages m JOIN users u1 ON (m.senderID=u1.user_id)
                JOIN receivedmessages r ON (m.id=r.messageId)
                JOIN users u2 ON (r.RecipientId=u2.user_id)
ORDER BY u1.user_name, m.sent_date, u2.user_name;

Answer 3

Я сталкиваюсь с той же проблемой создания системы электронной почты или обмена сообщениями для веб-сайта ... Вы, ребята, забыли одну вещь ... IsRead, IsDraft, IsFlagged, IsReply, IsTrash и т. Д. ... должны быть в отдельномтаблица, поскольку одно и то же сообщение будет помечено, прочитано или не прочитано двумя или более людьми !!Итак, у нас должна быть таблица состояния, как показано ниже ...

StatusID    int     
MessageID   int  
MemberID    int  
DateTime    datetime    
IPAddress   varchar(65)  
IsRead  char(1)   
IsDraft char(1)  
IsFlagged   char(1)   
IsForwarded char(1)  
IsReply char(1)  
IsTrash char(1) 

Вам понадобится как минимум три таблицы помимо таблицы участника или пользователя:

mail  
folders  
status  
attachment  
log  

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

Answer 4

Пользователи меняют имя и адрес электронной почты, но не их логин.Попробуйте вместо этого подражать тому, что происходит в почтовом ящике на основе Unix (например, pine):

received_messages (
  user_id,
  message_id,
  message_date,
  message_title,
  message_content,
  message_sender,
  message_recipient,
  message_is_read
)

и sent_messages по одной и той же линии, т. Е. Два "файла" на пользователя.

Или дажеобъединение последних двух с флагом отправки / получения.