我一直在四处寻找，试图在这里和谷歌上找到答案，尽管我找到了一些我还没有找到解决方案的指针。
如果您有一个带有数据库的简单 RSS 阅读器，您可能有几个表用于存储提要(这里忽略与订阅者的关系):
feed-url)
项目标题，项目内容)
这在大多数情况下都有效，但对于许多基于网站/网络的应用程序，您可能有来自首页的主要提要，然后是类别提要，如果您将两者都带入上述类型的系统，那么由于相同，将有大量复制数据帖子出现在几个 rss 提要中。
我提出的两个选择要么忽略它并接受重复项，要么在提要和项目之间使用链接表。但这似乎也是一种浪费，因为可能 80% 的我希望提取的提要不会有多个可以创建此复制的提要。
有没有更好的方法来做到这一点/我是否以完全错误的方式看待这个问题？
更新
感谢两位的回答，所以大家的共识似乎是节省的空间可能不足以担心，并且会被潜在的未知问题(如 dbr 提到的)所否定。
添加链接表或类似的内容可能也会增加处理时间，因此总体而言不值得担心太多。在阅读链接内容和删除重复项的回复后，我有一些想法，只有当帖子不再在任何一个 RSS 提要中以节省空间时，但正如 Assaf 所说，节省的空间可能会浪费时间。
最佳答案
我建议您不要尝试在开发的这个阶段(我认为是设计)优化掉所有可能的提要数据副本。集中精力让它工作，当你完成后，如果你做一些分析并发现如果你在提要之间使用链接或共享数据，你确实可以节省 X% 的存储空间，只有这样和 如果 X 大到足以支付优化数据库所需的时间 我会建议您实现任何此类更高级的计划。
关于database-design - 用于存储 RSS 提要的最佳数据库结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/624616/