2009-06-12 8 views
0

Angenommen, die Datenbank enthält Tabellen für Benutzer, Feeds, Elemente und die Möglichkeit, zu wissen, welche Elemente der Benutzer bereits gesehen hat. Ich bin auf der Suche nach einem Designparadigma, das auf dem Server verwendet werden kann, um in kurzer Zeit [feed id, num_unread] für jeden Feed zu berechnen, den der Benutzer abonniert hat.Was wäre ein guter Algorithmus, um ungelesene Elemente zu zählen? In einer Online-Feed-Aggregator-Implementierung?

Nehmen Sie viele Benutzer an und dass die Feeds regelmäßig im Back-End aktualisiert werden.

Edit: Ich wollte das Problem lösen, das Nick J erzogen hat (siehe unten). Aber ich schätze die Lösung von Cletus. Ich bin nicht so besorgt um die db-Abfragen, aber ich möchte ein "Design-Paradigma" - wie einen Watchdog-Prozess zu halten, der die ungelesenen Zählimpulse im Gedächtnis behält, damit sie an irgendeinem Punkt gedient werden kann.

Antwort

1

Ich bin mir nicht sicher, was ich Ihnen genau sagen soll, weil das, was Sie fragen, relativ einfach ist.

Zunächst einmal verwenden Sie Google Reader als Referenz für Online-Feed Aggregatoren/Leser. Und wenn Sie versuchen, die Funktionalität neu zu erstellen, hat Google Reader es schon ziemlich genau (imho) genagelt.

Google Reader funktioniert einfach durch Speichern einer Liste von Feeds. Im DB-Bedingungen, dann würden Sie wahrscheinlich diese Einheiten haben

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 

ungelesene Artikel:

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 

ungelesene Artikel von 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 

Und dann brauchen Sie nur einen Mechanismus zur Kennzeichnung Artikel wie gelesen. Im Fall von Google Reader gibt es nur AJAX-Aufrufe, die durch mouseover-Ereignisse mit zusätzlichen Links ausgelöst werden, um alles als gelesen zu markieren, ein Element als ungelesen markieren und so weiter.

+0

Das Problem, das Sie verpassen, ist, dass das Zählen ungelesener Elemente zur Laufzeit extrem ineffizient ist - O (n) für die Anzahl der ungelesenen Elemente - und daher in großem Umfang unpraktisch. Der Ansatz, den Reader damit anstellt, besteht darin, die Anzahl ungelesener Elemente, die gezählt werden sollen, zu begrenzen. –

+0

Ich vermisse es überhaupt nicht. Es ist einfach nicht relevant. Die Anzahl der Elemente, die Sie zur Laufzeit mit dem obigen Schema zählen können, ist in Wirklichkeit sehr groß und eine moderne Datenbank verwendet normalerweise nur den Index, anstatt die Zeilen zu lesen, um die Anzahl der ungelesenen Elemente zu ermitteln. Nicht optimieren. Das oben genannte ist ein solides Design. – cletus

+0

Ich füge nur hinzu, dass es wirklich wichtig ist, dass Sie zuerst ein solides Design bekommen. Dann und nur dann optimieren Sie es genau dann, wenn es nötig ist. In diesem Fall könnten Sie das Modell denormalisieren, indem Sie ungelesene Zählerstände im Benutzer-Feed speichern, aber nicht auf diese Weise beginnen. Das bedeutet, dass Sie Probleme beim Aktualisieren von Werten in zwei Tabellen haben müssen, wenn ein Element gelesen wird und die Werte nicht mehr synchron sind. – cletus