您将使用哪种数据库模式将包含尽可能多的标题信息的电子邮件消息存储到数据库中?
假设它们已从 MTA 输入脚本并解析为相关的标题/正文/附件。
您会将消息正文整体存储在数据库表中,还是将任何 MIME 部分分开?附件呢?
您可能希望使用可以在邮件的多个收件人之间共享邮件正文和附件记录的模式。经常会看到电子邮件服务器中 50% 的磁盘存储空间被重复的电子邮件使用。
正文/附件的简单散列足以查看该记录是否已在数据库中。但是,您仍然需要保留单独的标题。
取决于你要用它做什么。如果您需要对其中的某些部分进行频繁的搜索,则需要以对您的用例有意义的方式将其分解。如果只是为了符合 Sarbanes-Oxley 标准而存储电子邮件,您可能可以将整个内容(标题、部分等)存储为一个大文本字段。
建议:创建一个定义明确的表来存储电子邮件,并为邮件的每个相关部分设置一列:发件人、标题、主题、正文。如果您想查询,例如,按主题字段,稍后会简单得多。在同一个表中,您可以定义一个字段来保存附件的路径并将附件存储在文件系统上,而不是将其存储在 blob 字段中。
数据库模式设计的一个重要步骤是确定要建模的实体类型。对于此应用程序,实体可能是:
一旦你知道了实体,你就可以识别实体之间的关系,这些关系可以用表来表示:
In-Reply-To
消息与消息(和标头)具有多对多的关系References
。From
消息与电子邮件地址( 、To
等Cc
标题)具有多对多的关系。您可能希望至少单独存储附件以优化存储。大多数用户毫不犹豫地附加到电子邮件中的附件(视频等)的大小和数量令人惊讶。
在外发电子邮件的情况下,您可能有多封电子邮件发送相同的附件。存储所有共享它的电子邮件引用的附件的单个副本效率更高。
单独存储附件的另一个原因是它稍后会为您提供一些归档选项。如果存储空间成为问题,您可以随时返回并删除早于给定日期的大型附件,以压缩数据库。
这完全取决于您想对数据做什么,但总的来说,我希望存储所有数据,并确保 MUA 解释的语义保留在数据库中,例如: - 解析的所有标头应该有自己的列 - 列应该包含整个标题 - 附件(包括正文、多部分)应该与电子邮件表位于多对一表中。
如果它已经被拆分,并且您可以确定拆分数据的例程是正确的,那么我会尽可能精细地拆分表。您始终可以在中间层将其重新解析。如果空间不是问题,您总是可以存储两次。一个,拆分为相关字段,另一个字段将整个事物作为一个 blob,如果将其重新组合起来很困难。