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

Question

Какой тип схемы базы данных вы бы использовали для хранения сообщений электронной почты с максимально возможной / возможной информацией заголовка в базе данных?

Предположим, что они были переданы в сценарий из MTA и проанализированы в соответствующих заголовках / теле / ​​вложениях.

Будете ли вы хранить тело сообщения целиком в таблице базы данных или разделять какие-либо части MIME? А как насчет вложений?

Answer 1

Возможно, вы захотите проверить архитектуру и схему DB в Archiveopteryx.

Answer 2

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

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

Answer 3

Предложение: создайте четко определенную таблицу для хранения электронной почты со столбцом для каждой соответствующей части сообщения: отправитель, заголовок, тема, тело. Позже будет намного проще, если вы захотите сделать запрос, например, по предметной области. В этой же таблице вы можете определить поле для хранения пути вложения и сохранить вложенный файл в файловой системе, а не хранить его в полях BLOB-объектов.

Answer 4

Зависит от того, что вы собираетесь с ним делать. Если вам нужно будет часто выполнять поиск по определенным частям, вам нужно разбить его так, чтобы это имело смысл для вашего случая использования. Если это просто что-то вроде хранения электронной почты для соответствия требованиям Сарбейнса-Оксли, вам, вероятно, будет хорошо хранить все это - заголовки, части и т. Д. - как одно большое текстовое поле.

Answer 5

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

• Сообщения
• Адреса электронной почты
• Темы для разговоров (возможно: если вы хотите сделать эффективные потоки)
• Приложения (возможно: как предложено в других ответах)
• ...

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

• Сообщения имеют много-много отношение к сообщениям (In-Reply-To и References заголовки).
• Сообщения имеют много-много связей с адресами электронной почты (From, To, Cc и т. Д.).
• Сообщения имеют много-одну связь с темами.
• Сообщения имеют много-много связей с вложениями.
• ...

Answer 6

Возможно, вы захотите, по крайней мере, хранить вложения отдельно для оптимизации хранилища. Удивительно видеть размер и количество вложений (видео и т. Д.), Которые большинство пользователей без колебаний прикрепляют к электронным письмам.

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

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

Answer 7

Все зависит от того, что вы хотите сделать с данными, но в целом я хотел бы сохранить все данные, а также убедиться, что семантика, интерпретируемая MUA, сохраняется в БД, например: - Все анализируемые заголовки должны иметь свой собственный столбец. - столбец должен содержать целые заголовки - Вложения (включая основной, составной) должны быть в таблице «многие к одному» с таблицей электронной почты.

Answer 8

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

/ Allan

Answer 9

Если оно уже разделено, и вы можете быть уверены, что процедура разделения данных является правильной, то я бы разделил таблицу как можно более детально. Вы всегда можете разобрать его вместе на своем среднем уровне. Если пространство не является проблемой, вы всегда можете сохранить его дважды. Одно разделить на соответствующие поля, а другое поле, в котором все целиком представляет собой один BLOB-объект, если сложить его обратно сложно.