Question

我一直在寻找这里和谷歌的答案，虽然我找到了一些指示我还没有找到解决方案。

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

Feed（ feed-id ，Feed-title，馈URL）
项目（ item-id ， feed-id ， item-title，item-content）

这适用于大多数情况，但对于许多基于网站/网络的应用程序，您可能从首页获得主要供稿，然后是类别供稿，如果您同时使用上述类型的系统，则会有大量复制数据到期到几个rss feed出现的同一帖子。

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

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

更新

感谢两者的答案，所以共识似乎是空间的节约可能不足以担心，并且可能会因未知问题的可能性而被否定（例如dbr提到的）。

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

Answer 1

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

Answer 2

正如阿萨夫所说，至少现在我不会担心存储重复的文章，如果它们来自不同的饲料。它会增加的复杂性并没有使你节省的几千字节空间受益..

我想如果你对内容进行sha1哈希，请SELECT id FROM articles WHERE hash = $hash，如果存在，只需要一个“article_content_id”，如果设置将文章内容指向另一行...但是，如果你怎么办？有两篇文章：

id: 1
title: My First Post!
feed: Bobs site
content: Hi!
hash: abc
link: no
content_link_id:

id:2
title: My First Post!
feed: Planet Randompeople Aggregator
content:
hash: abc
content_link_id: 1

..这样可以正常工作，你通过不重复文章节省了3个字节（如果文章更长，显然更多）

..但是当Bob决定将广告添加到他的RSS源，将内容从Hi!更改为Hi!<p><img src='...'></p>时会发生什么 - 但是Planet Randompeople会删除所有图片。然后，要更新供稿项，您必须检查content_link_id - 链接您要更新的文章的每一行，检查新项目是否与链接它的文章具有相同的哈希值 - 如果它不同，你必须打破链接并将旧数据复制到链接项，然后将新内容复制到原始项..

可能有更简洁的方法可以做到这一点，但我的观点是它可能变得非常复杂，并且您可能只会在非常有限的子集上保存几千字节（假设数据库引擎本身不进行任何压缩）。帖子..

除此之外，拥有feeds和items的表似乎是明智的，这也是我见过的大多数其他RSS存储数据库处理它的方式..

存储RSS提要的最佳数据库结构

2 个答案: