我正在使用 LAMP 构建一个 feed(rss、twitter、其他服务等)聚合器。它与 Google Reader 非常相似，人们可以根据需要添加任意数量的提要，然后能够一次阅读他们的提要、对其进行排序、查看单个提要或提要组。
我以前建立过这种类型的服务，但针对的是一小部分有限的人，整个群体都可以访问所有汇总的 Feed 项目。所以，这非常简单。
然而，这一次，我正在构建一项人们可以订阅的服务，因此我可能(理想情况下)拥有数千名用户和数十万个提要，进而拥有数百万个提要项。
我的数据库模式(简化)方法是这样的:
users (id, name, ...)
feeds (id, name, url, ...)
feed_items (id, title, timestamp, feed_id, ... )
user_feeds (id, user_id, feed_id, ...)
但是，由于用户可以订阅 100 个提要，我正在尝试制定最佳和最优化的方式来查询数据库以获取他们订阅的提要(或其子集)的 feed_items。
最佳答案
我认为您走在正确的轨道上。我以前做过(几次)，重要的是弄清楚哪个表需要包含哪些信息。例如，在我的 USERS 表中，我保留了用户订阅列表(或 OPML)的缓存副本。如果您要允许用户跟踪每篇文章的已读/未读状态，您可能希望将该元数据保存在单独的表中。相反，我看到您已经为用户 <-> 提要关系设置了一个关系表。这允许您在 FEED 表中只保留每个提要的一个副本，但查询复杂性(和性能)的权衡可能不值得。考虑您希望运行的查询。
例如，我的用户的主“主页”是一个“文件夹”列表(即 Google 阅读器标签)，提要被隔离到其中，每个文件夹都标有该文件夹中未读文章的数量(不计算在内)重复的文章)。即使有良好的索引，这也是使用关系方法的查询(而且很慢)的负担。但是，如果您对其进行非规范化(即，FEEDS 表可能包含每个提要的多个副本，并且架构包含 user_id(在我的例子中，还有文件夹名称))，该表更大，但该查询很简单且即时。
此外，在我的 POSTS 表(或 FEED_ITEMS —— 随便)中，我将原始文章描述/内容:编码存储在 DESCRIPTION_ORIGINAL 列中，然后将“干净”版本放入 DESCRIPTION 列中。干净版本对 HTML 进行了清理，删除了广告，修复了已知的编码问题等。
关于php - 用于多用户体验的 Feed 聚合器数据库逻辑，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8610093/