在数据库中存储电子邮件

取决于你要用它做什么。如果你需要经常搜索它的某些部分，你会希望以一种对你的用例有意义的方式将其分解。如果只是为了满足 Sarbanes-Oxley 法规遵从性而存储电子邮件，那么您可以将整个内容（标题、部件等）存储为一个大文本字段。

这完全取决于你想对数据做什么，但一般来说，我想要存储所有数据，并确保 MUA 解释的语义保留在数据库中，例如： - 所有解析的标题都应该有自己的列 - 一列应包含整个标题 - 附件（包括正文、多部分）应与电子邮件表位于多对一表格中。

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

如果它已经被拆分了，并且您可以确定拆分数据的例程是合理的，那么我会尽可能细化地拆分表。您始终可以在中间层中将其重新解析。如果空间不是问题，您可以随时将其存储两次。一个是拆分为相关字段，另一个字段将整个事物作为一个 blob 进行，如果将其重新组合在一起很困难。

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

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

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

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

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

您可能需要检查“Archiveopteryx”的架构和数据库模式。

数据库架构设计的一个重要步骤是确定要建模的实体类型。对于此应用程序，实体可能是：

• 消息
• 电子邮件地址
• 对话线程（也许：如果你想做有效的线程）
• 附件（也许：如其他答案中所建议的）
• ...

了解实体后，可以识别实体之间的关系，这些关系可以用表表示：

• 消息与消息（和标头）具有多对多关系。In-Reply-ToReferences
• 邮件与电子邮件地址（、 等标头）具有多对多关系。FromToCc
• 消息与线程具有多对一关系。
• 邮件与附件具有多对多关系。
• ...