在数据库中存储电子邮件

您将使用哪种数据库模式将具有实际/可能的头信息的电子邮件存储到数据库中？

假定已将它们从MTA馈入脚本并解析为相关的标头/正文/附件。

您是将整个消息正文存储在数据库表中，还是将任何MIME部分分开？附件呢？

您可能要检查" Archiveopteryx "的体系结构和数据库架构。

您可能希望使用一种架构，可以在邮件的多个收件人之间共享邮件正文和附件记录。看到电子邮件服务器中重复的电子邮件完全使用了50％的磁盘存储空间并不少见。

简单的主体/附件哈希足以查看该记录是否已在数据库中。但是，您仍然需要保留单独的标题。

建议：创建一个定义明确的表，用于存储电子邮件，并在邮件的每个相关部分(发件人，标头，主题，正文)创建一列。如果您想按主题字段进行查询，以后将变得更加简单。在同一表中，您可以定义一个字段来保留附件的路径并将附件文件存储在文件系统上，而不是将其存储在blob字段中。

取决于您要使用它做什么。如果您将需要频繁搜索某些内容，则需要以一种适合您使用情况的方式对其进行分解。如果仅用于存储符合Sarbanes-Oxley要求的电子邮件之类的内容，则可以将整个内容(标头，部分等)存储为一个大文本字段。

数据库架构设计中的重要一步是弄清楚您要建模的实体的类型。对于此应用程序，实体可能是：

• 留言内容
• 电子邮件地址
• 会话线程(也许：如果您想进行高效的线程处理)
• 附件(也许：如其他答案所示)
• ...

一旦了解了实体，就可以标识实体之间的关系，这些关系可以用表来表示：

• 消息与消息(In-Reply-To和References标头)有很多关系。
• 邮件与电子邮件地址(From，To，Cc等标头)有很多关系。
• 消息与线程具有多一关系。
• 邮件与附件之间存在许多关系。
• ...

您可能希望至少单独存储附件以优化存储。看到大多数用户毫不犹豫地附加到电子邮件的附件(视频等)的大小和数量令人惊讶。

对于外发电子邮件，您可能有多封电子邮件发送相同的附件。存储共享它的所有电子邮件所引用的附件的单个副本要高效得多。

另一个单独存储附件的原因是，稍后它会为您提供一些归档选项。如果存储空间成为问题，您可以随时返回并删除早于给定日期的大型附件，以压缩数据库。

这一切都取决于您要对数据执行什么操作，但是一般而言，我要存储所有数据，并还要确保将MUA解释的语义保留在db中，例如：
-所有已解析的标头应具有自己的列
-一栏应包含整个标题
-附件(包括正文，多部分)应与电子邮件表放在多对一表中。

解析电子邮件并非易事，因此请考虑将电子邮件存储为blob，然后将其解析为以后需要的任何片段。

如果已经拆分了该表，并且可以确定拆分数据的例程是正确的，那么我将拆分表的粒度尽可能小。您始终可以在中间层将其解析回去。如果空间不是问题，则可以始终存储两次。如果很难将其放回原处，则将其拆分为相关的字段，然后将整个内容作为一个blob将其划分为另一个字段。