Проектирование баз данных почтовой рассылки

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

Прямо сейчас чтобы упростить у меня есть что-то вроде этого:

Lists:
ID,
Name

Subscribers:
ID
Email
Name

ListSubscribers:
ID
SubscriberID
ListID

Messages:
ID
Title
Content
ListID

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

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

MessageStatus:
ID
MessageID
SubscriberID
Status (processing, sent, soft bounce, hard bounce)

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

Есть ли более эффективный способ сделать это?

0
nl ja de
Как это происходит, я недавно добавил способность списка рассылки к программе, которую я пишу и поддерживаю; я спросил клиентку, хотела ли она отслеживать почтовое содержание и кому их послали. Она придумала простой ответ: пошлите клиенту копию каждой почты. Таким образом, клиент знает и содержание каждой электронной почты и кому это послали без потребности сохранить это в базе данных.
добавлено автор No'am Newman, источник

2 ответы

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

Учитывая, что необходимо управлять пространством для MessageStatus , вы могли управлять с точки зрения списком работы , а не контрольный журнал - если, конечно, у вас не должно быть контрольного журнала по некоторым причинам.

Чтобы сделать это, используйте ваш MessageStatus стол, поскольку вы определили его, за исключением того, что, когда отчет добирается до "ПОСЛАННОГО" статуса, удалите его вместо того, чтобы обновить его. Таким образом, у вас только есть столько же отчетов, сколько есть электронные письма, которые должны все же быть посланы.

1
добавлено
  • Список (стол): ListID (PK), ListName

  • Подписчик (Стол): SubscriberID (PK), ListID (FK), FirstName, LastName, EmailAddress

  • электронная почта (стол): EmailID (PK), ListID (FK), Предмет, Содержание, SendDate

1
добавлено
Может быть проблема с этим дизайном: пока каждый знает то, чем было содержание электронной почты и в который список ее послали, один doesn' t обязательно знают, кто был членом того списка в день, электронное письмо было послано.
добавлено автор No'am Newman, источник
dbGeeks
dbGeeks
545 участник(ов)

Чат про базы данных, их устройство и приемы работы с ними. Разрешаются любые адеватные дискуссии в рамках тематики чата.

Разработка СУБД
Разработка СУБД
143 участник(ов)