✔ Benachrichtungen bei Kommentar-Antworten

MsvP@habdichliebhasi

MsvP@habdichliebhasi

Erfahrenes Mitglied
Hallo zusammen,

ich grübel derzeit darüber, wie ich eine Benachrichtungs-Funktion sinnvoll umsetze. Folgendes will ich realisieren:

User 1 schreibt einen Kommentar (ID 1).
User 2 antwortet auf den Kommentar (ID 1) mit dem Kommentar (ID 2).
User 1 antwortet ebenfalls (ID 1) mit dem Kommentar (ID 3).
User 3 antwortet ebenfalls (ID 1) mit dem Kommentar (ID 4).

Jetzt möchte ich, dass die User solange eine Information auf ihrer Seite erhalten, bis sie die Antwort des anderen gelesen haben.

Am einfachsten wäre es, einfach einen "gelesen / ungelesen" Status in die Datenbank zu speichern. Allerdings fürchte ich, dass dadurch die Datenbank aus allen Nähten platzt.

Wenn ich jetzt für jeden Benutzer (1, 2 und 3) einen Status in die Datenbank packe, der speichert, ob er den Beitrag gelesen hat - dann könnte das irgendwann überhand nehmen, oder?

Genauso anders herum, wenn ich beim posten einer Antwort einen Status "ungelesen" in die Datenbank speichere, und diesen rauslösche, sobald der User die Antwort aufruft, wird zwar die Datenbank nicht so schnell voll, da ja der Eintrag wieder gelöscht wird, aber sollten viele User auf einen Kommentar geantwortet haben, müsste ich ja für jeden User einen extra Status beim speichern der Antwort speichern... also auch irgendwie unpraktikabel.

Habt ihr eine Idee?

Lg
Micha
 
Danke für den Link. Gute Ansätze, aber ne wirkliche Lösung bietet der Thread auch nicht. Vielleicht ists auch Geschmackssache... verdammt, hätte es mir nicht so kompliziert vorgestellt. -.-
 
Den Status "ungelesen" kannst du auch ersetzen, indem du keinen Eintrag machst. Sprich: Wenn in einer Tabelle, die den gelesen-Status zu jedem Thread und User beherrbergt, kein Eintrag für einen User vorhanden ist, hat er den Thread auch noch nicht gelesen. Entsprechend löschst du alle Einträge zu einer Thread-ID, wenn ein neuer Kommentar hinterlassen wird.
Um das ganze nicht ewig fortzuführen, solltest du überlegen, nach einer bestimmten Zeit nach dem letzten Kommentar den Thread generell als gelesen anzuzeigen und die Einträge dazu aus der DB nehmen. Das verkleinert den Speicherplatzbedarf.
 
Tabelle "status" mit den Feldern "von", "an" und "id", "id2", "datum".

Code: 
VON  : Von wem ist der Beitrag
AN   : An wen ist der Beitrag
ID   : Die ID des Originalbeitrags
ID2  : Die ID des jew. Kommentars
DATUM: Das Datum und die Uhrzeit wann der Beitrag erstellt wurde
So bald jetzt ein neuer Kommentar geschrieben wird, wird hier ebenfalls ein Eintrag gemacht. Ist ein solcher Eintrag vorhanden bekommt der entsprechende User die Mitteilung das es einen ungelesenen Beitrag gibt.
Liest er den Beitrag so wird (wie auch erik s. schreibt) der Eintrag aus der Tabelle gelöscht.
 
Geht es bei dir denn um ein Forum, oder um private Nachrichten oder eine Kommentarfunktion?
Beim Forum ist Erik S. Lösung imho die sinnvollste, vielleicht noch ergänzt um einen Zeitstempel, der sich merkt wenn ein User auf "Alle Beiträge als gelesen markieren" geklickt hat. Selbst wenn du sehr viele User hast, werden niemals alle einen Thread lesen, daher bleibt die Anzahl der Einträge in der DB klein. Man könnte sogar über eine Komprimierungsfunktion nachdenken, die nachts per Cron diese Einträge durchsucht und zusammenhängende Bereiche zusammenfasst (100,101,102...,199,200 zu 100-200).
Für private Nachrichten ist der Vorschlag von tombe besser. Hier sollte man dann die maximale Anzahl an Nachrichten begrenzen z.B. max 50 Nachrichten pro User, damit der Speicherbedarf überschaubar bleibt.
 
Erst einmal vielen Dank für eure Lösungsansätze. Gefallen mir schon sehr gut. Jetzt müssten wir noch einen Favoriten finden, der am Besten passt. :)
Ich hatte zwischenzeitlich auch überlegt, ob ich den Kommentaren in der Datenbank ein Feld "antworten (longtext)" hinzufüge - wo dann Komma separiert alle User eingetragen werden, die diesen Beitrag noch nicht gelesen haben. Und dann per preg_replace / str_replace die User-ID rauslösche. - Evtl ist das nicht ganz so speicher intensiv, wie eine eigene Tabelle.
Wobei, wenn ich die ungelesenen Einträge einfach nach zwei Wochen löschen lasse, wärs wahrscheinlich mit ner extra Tabelle auch egal.

Nochmal im Detail wofür ich es brauche:
Bei mir geht es um eine Kommentarfunktion. Und die Benachrichtigungen brauche ich für eine Facebook-ähnliche Anzeige. Das heißt, man sieht oben im Seitenheader was neues passiert ist auf der Plattform. Und wenn jemand z.B. auf einen Kommentar geantwortet hat, dann soll dort oben stehen "XY hat auf deinen Kommentar XY geantwortet".
Da aber auch Benutzer informiert werden sollen, die ebenfalls bereits geantwortet haben, dass eine neue Antwort dazugekommen ist, muss ich diesen Status eben für jeden User, der jemals auf diesen Kommentar geantwortet hat nachhalten. Also ob er den gelesen hat, oder eben nicht.

Wobei, ist es nicht sehr aufwändig (Traffic), dann bei jeder Antwort für jeden Benutzer einen Eintrag in die Datenbank zu speichern? Wenn da nacher 1.000 User an einer Diskussion beteiligt sind - dann müsste ich ja bei jeder Antwort 1.000 "ungelesen" Einträge in die Datenbank speichern....

Okey - meine Gedanken kreisen gerade. Und ich bin jetzt beim Vorschlag von Eric S. gelandet (ähnlich wie es ikosaeder auch schon gesagt hat). Ich speichere immer nur dann etwas in die Datenbank, wenn der User es "gelesen" hat. Also pro User, der es liest, gibt es einen Beitrag. Damit die DB nicht aus allen Nähten platzt, lösche ich alle zwei Wochen, die alten Beiträge (z.B. via Cronjob). Die Prüfung geht dann immer nur, ob zwei Wochen zurück neue Beiträge vorhanden sind, die nicht gelesen wurden. Danach werden die Beiträge automatisch als gelesen markiert.

Denke, so sollte es den wenigsten Traffic und Speicherplatz kosten.
 
Bitte in Zukunft die Editier-Funktion des Forums benutzen...

Das mit der Komma-Liste - Mööp. Da ist eine Tabelle mit nur wenigen ID-Feldern, guten Indexen und 1 Million Einträge immer noch schneller.
 
Wenn da nacher 1.000 User an einer Diskussion beteiligt sind - dann müsste ich ja bei jeder Antwort 1.000 "ungelesen" Einträge in die Datenbank speichern....
Zum Vergrößern anklicken....

Du speicherst die User ab, die den Thread gelesen haben. Das werden immer weit weniger als 1000 sein.

Genauer:
Es würde reichen, wenn du wie Erik schreibt, speicherst wer den Kommentar gelesen hat. Du musst ja dann nur auslesen wer den letzten Post geschrieben hat um das für dein "XY hat auf Kommentar XY geantwortet". zu verwenden. Und wenn du dann abgleichst, wer den Thread erstellt hat, kannst du den User auch gesondert benachrichtigen.
Du musst dann für jeden Kommentar speichern
ID | Text | Ersteller | Datum | Letzter Post am | von | Gruppe | gelesen
wobei Gruppe optional ist und auf eine Tabelle verweist, die z.B. User enthält, die einen Thread abonniert haben.
Wenn sich dann ein User anmeldet liest du den Zeitstempel der letzten Anmeldung aus der Userdatenbank und gleichst für alle Kommentare die neuer sind die UID mit Ersteller und gelesen (und evt. Gruppe) ab.

Yaslaw hat gesagt.:
Das mit der Komma-Liste - Mööp. Da ist eine Tabelle mit nur wenigen ID-Feldern, guten Indexen und 1 Million Einträge immer noch schneller.
Zum Vergrößern anklicken....
Du meinst also, dass man für jeden Kommentar eine extra Tabelle anlegt, und in der die UserID
ID | UID speichert die den Thread gelesen haben?
Verglichen mit einer Liste von UID's mit einem Trennzeichen in einem String.
Ich denke, das man nicht pauschal sagen kann was schneller ist, ein Lookup in der Tabelle oder ein explode in php. Könnte ja mal vielleicht jemand testen. Ich vermute, das es für User < 1000 mit PHP schneller ist, vor allem weil man dann die UID bereits in einem Array hat, das man direkt weiterverarbeiten kann.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück