Question

Assume the database has tables for Users, Feeds, Items, and an ability to know which Items the user has already seen. I am looking for a design paradigm that can be used on the server to compute in a short amount of time [feed id, num_unread] for each feed that the user has subscribed to.

Assume plenty of users and that the feeds are getting updated periodically in the backend.

Edit: I wanted to solve the problem Nick J has brought up (see below). But I appreciate the solution posted by cletus. I am not so worried about the db queries, but want a “design paradigm” — like keeping a watchdog process that keeps the unread counts in memory so that it can be served at any point.

Answer 1

I’m not sure what to tell you exactly because what you’re asking is reasonably straightforward.

First off, use Google Reader as a reference for online feed aggregators/readers. And if you’re trying to recreate the functionality, Google Reader has pretty much nailed it already (imho).

Google Reader works simply by storing a list of feeds. In DB terms, you’d probably have these entities

User: id, name, email, etc...
Feed: id, feed_name, feed_url
Content: id, feed_id, title, content
User Feed: id, user_id, feed_id, user_label, has_read

Unread items:

SELECT COUNT(1)
FROM user u
JOIN user_feed uf ON uf.user_id = u.id
JOIN feed f ON f.id = uf.feed_id
WHERE has_read = 0

Unread items by feed:

SELECT feed_id, feed_name, COUNT(1)
FROM user u
JOIN user_feed uf ON uf.user_id = u.id
JOIN feed f ON f.id = uf.feed_id
WHERE has_read = 0
GROUP BY feed_id, feed_name

And then you just need some mechanism for marking items as read. In Google Reader’s case, there are just AJAX calls triggered by mouseover events with additional links to mark everything as read, leave an item marked as unread and so on.