您将使用哪种数据库架构将电子邮件消息与实际/可能的头信息一起存储到数据库中?
假设它们已从MTA输入脚本并解析为相关的标题/正文/附件。
您是将整个邮件正文存储在数据库表中,还是将所有MIME部分拆分?附件怎么样?
答案 0 :(得分:12)
您可能需要查看“Archiveopteryx”的architecture和DB schema。
答案 1 :(得分:4)
取决于你将要用它做什么。如果您需要经常搜索它的某些部分,您将需要以对您的使用情况有意义的方式进行分解。如果只是为了存储电子邮件以满足“萨班斯 - 奥克斯利法案”的要求,那么您可能可以将整个内容 - 标题,部件等 - 存储为一个大文本字段。
答案 2 :(得分:4)
建议:创建一个定义良好的表,用于存储电子邮件,其中包含邮件的每个相关部分的列:发件人,标题,主题,正文。如果你想查询,例如,通过主题字段,它会更加简单。在同一个表中,您可以定义一个字段以保留附件的路径并将附加文件存储在文件系统中,而不是将其存储在blob字段中。
答案 3 :(得分:4)
您可能希望使用一种架构,其中邮件正文和附件记录可以在邮件的多个收件人之间共享。在电子邮件服务器中,重复电子邮件使用完全50%的磁盘存储空间并不罕见。
正文/附件的简单哈希足以查看该记录是否已存在于数据库中。但是,您仍然需要保留单独的标题。
答案 4 :(得分:2)
数据库架构设计中的一个重要步骤是确定要建模的实体类型。对于此应用程序,实体可能是:
了解实体后,您可以识别实体之间的关系,可以用表格表示:
In-Reply-To
和References
标题)有很多关系。From
,To
,Cc
等标题。)答案 5 :(得分:1)
这一切都取决于你想对数据做什么,但一般来说我想存储所有数据,并确保MUA解释的语义保留在db中,例如: - 解析的所有标头都应该有自己的列 - 列应包含整个标头 - 附件(包括正文,多部分)应与电子邮件表在多对一表中。
答案 6 :(得分:1)
您可能希望至少分别存储附件以优化存储。看到大多数用户毫不犹豫地附加到电子邮件的附件(视频等)的大小和数量令人惊讶。
如果是外发电子邮件,您可能会有多封电子邮件发送相同的附件。存储由共享它的所有电子邮件引用的附件的单个副本效率要高得多。
单独存储附件的另一个原因是它稍后会为您提供一些存档选项。如果存储空间成为问题,您可以随时返回并删除超过给定日期的大型附件,以压缩数据库。
答案 7 :(得分:0)
如果它已经拆分,并且您可以确定分割数据的例程是合理的,那么我会尽可能精细地分割表格。您始终可以在中间层中将其解析回来。如果空间不是问题,您可以始终存储两次。一个,分成相关的领域,另一个整体作为一个blob的领域,如果把它重新组合起来很难。
答案 8 :(得分:0)
解析电子邮件并非易事,因此请考虑将电子邮件存储为blob,然后将其解析为之后需要的任何部分。
/阿伦