Datenbankdesign

cd_brenner

Aktives Mitglied
Hallo Community,

zur Zeit programmiere ich an einer PHP Software die unter anderem ein Nachrichtensystem enthält. Verschiedene Quellen speisen Statusupdates in die Datenbank ein die dann dem Benutzer über eine AJAX Schnittstelle präsentiert werden.
So weit, so gut. Allerdings finde ich jetzt keinen schönen Weg für das Speichern der "Gelesen-Flags".
Zu beachten ist, dass ein Update von mehreren Benutzern gelesen werden kann, demnach muss nach 1:n verknüpft werden.
Soweit auch kein Problem, einfach eine Tabelle die user_id mit update_id verknüpft.

Wenn jetzt ein Eintrag in dieser Tabelle ein "gelesen-Flag" darstellt, dann fasst diese Tabelle Statusupdates * User Einträge (wenn alle gelesen sind), oder der Eintrag repräsentiert ein "ungelesen-Flag", dann ist zwar die Tabelle immer recht klein - was mir wesentlich besser gefällt, da einfach weniger Datenmüll anfällt und ein Datenverlust keine Massenflut an alten Updates auslöst - aber beim Erstellen > EINES < Updates müssen Useranzahl INSERTs gemacht werden, was mir auch nicht besonders gefällt.

Was mich jetzt interessiert ist, ob es noch andere Möglichkeiten gibt dieses Problem "schön" zu lösen. Eventuell auch "das Pferd von hinten aufzäumen".

Weiters hab ich noch eine "Beifrage":

In diesem Projekt verwende ich zum ersten Mal die AJAX-Technologie und bin sehr begeistert davon. Toll für dynamische Projekte und in Verbindung mit JQUERY auch super praktisch und einfach zu verwenden.
Aber bei Inhalten die möglichst aktuell sein sollen und sich in kurzen aber unbestimmten Zeitabschnitten ändern (sprich Chat) kommt man um Polling nicht herum. Jedoch entsteht bei mehreren Benutzern die alle mit 1sec pollen schon einiges an Last.
Mein Ansatz wäre a.) MD5 Checksummen vergleichen und nur bei Datenänderung übertragen und b.) bei Überlast die Aktualisierungsrate verlängern und so das System bremsen. Ich denke das sollte machbar sein.

Wieder die gleiche Fragestellung wie oben und was mich nich interessierten würde: Wird sowas irgendwo sinnvoll verwendet?

Vielen Dank,
Markus
 
Hallo Markus

Eine user_id / update_id - Tabelle ist IMHO sicher die sauberste Lösung.

Ist es in Deinem Projekt überhaupt vorgesehen, dass ein Update gelöscht wird?

Falls nicht könntest Du die ID's der gelesenen Updates in Form eines Komma separierten Strings in die User-Tabelle speichern. Spart Dir zwar eine Tabelle ist aber wesentlich weniger sauber und mit dem Parse-Problem verknüpft.

Den ursprünglichen Tabellenaufbau erlaubt Dir einfach am meisten aus den Daten herauszuholen. So kannst Du jederzeit anzeigen lassen, wieviel User ein Update gelesen haben. Und falls Du den Eintrag in die Tabelle noch mit eine Timestamp versiehst hast Du gleich noch mehr Infos zum Auswerten.

Lieber Gruss
Alain
 
Vielen Dank für deine Antwort!

QUOTE Den ursprünglichen Tabellenaufbau erlaubt Dir einfach am meisten aus den Daten herauszuholen. So kannst Du jederzeit anzeigen lassen, wieviel User ein Update gelesen haben. Und falls Du den Eintrag in die Tabelle noch mit eine Timestamp versiehst hast Du gleich noch mehr Infos zum Auswerten.


Ich denke, das ist auf jeden Fall ein pro-Argument. Je mehr Daten zur Verfügung stehen, desto lustiger wird das Aufbereiten.

Das herumfrickeln mit Strings ist mir dann doch zu exotisch, und Tabellen knausern führt zu nichts.

Viele Grüße.



 
Zurück
Oben