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

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

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

解决方案

回答

取决于我们将要使用的功能。如果我们需要经常对其进行某些部分的搜索，则需要以一种适合使用情况的方式对其进行分解。如果仅用于存储类似于Sarbanes-Oxley法规的电子邮件之类的内容，则可以将整个标头，部件等存储为一个大文本字段，这可能是可以的。

回答

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

回答

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

回答

如果已经拆分过，并且可以确定拆分数据的例程是正确的，那么我将拆分表尽可能的细。我们总是可以在中间层将其解析回去。如果空间不是问题，则可以始终存储两次。如果将其放回原处，则很难将其拆分为相关领域，而将整个事物归为一团是很难的。

回答

解析电子邮件并非易事，因此请考虑将电子邮件存储为Blob，然后将其解析为以后所需的任何内容。

/艾伦

回答

我们可能希望使用一种架构，在该架构中，可以在邮件上的多个收件人之间共享邮件正文和附件记录。电子邮件服务器经常有50％的磁盘存储空间被重复的电子邮件使用的情况并不少见。

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

回答

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

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

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

回答

我们可能要检查" Archiveopteryx"的体系结构和数据库模式。

回答

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

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

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

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