数据库设计 – 用于存储RSS提要的最佳数据库结构

我一直在寻找这里和谷歌的答案,虽然我已经找到一些指示我还没有找到解决方案.

如果你有一个带有数据库的简单RSS阅读器,你可能有几个用于存储提要的表(忽略在这里处理订阅者)：

>饲料(饲料ID,饲料标题,
饲料网址)
>项目(item-id,Feed-id,
item-title,item-content)

这适用于大多数情况,但对于许多基于网站/网络的应用程序,您可能从首页获得主要供稿,然后是类别供稿,如果您同时使用上述类型的系统,那么由于相同的原因,将会有大量的复制数据帖子出现在几个RSS源中.

我提出的两个选择是忽略它并接受重复项或使用源和项之间的链接表.但是,当我想要提取的那种饲料中有80％没有多个可以创建这种复制的源时,这似乎也是一种浪费.

有没有更好的方法这样做/我是以完全错误的方式看待这个？

更新

感谢两者的答案,所以共识似乎是空间的节约可能不足以担心并且可能被未知问题的可能性所抵消(例如dbr提到的).

添加链接表或类似链接可能会增加处理时间,因此总体上不值得担心太多.我在阅读链接内容和删除重复项的响应之后想到了只有当帖子不再用于任何RSS提要以节省空间时,但是再次像Assaf所说的那样,空间节省可能会浪费时间.

解决方法

我建议你不要试图在这个开发阶段(设计,我认为)优化掉每一个可能的饲料数据副本.专注于让它工作,当你完成时,如果你进行一些分析,发现你确实可以节省X％的存储空间,如果你在Feed之间使用链接或共享数据,那么只有当X足够大以支付我需要时间来优化您的数据库,我建议您实施任何此类更高级的方案.