Forum posting als gelesen "taggen"
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
abfrage
bit
byte
code
datenbank
dimension
feld
forum
grad
idee
komma
minute
nachricht
spalte
speichern
string
system
tabelle
umsetzen
zeichen
-
So, auch wenn das hier wenig mit quellcodes, als viel mehr mit "denkarbeit" zu tun hat, poste ich das mal hier, da es wenn überhaupt mit php und mysql zutun hat.
Es geht um folgendes: Ich schreibe seit geraumer Zeit an einer kleinen "Community" - nichts wirklich großes, oder gar "professionelles". Ich mache das aus reiner Lust am lernen. Deshalb greife ich auf so wenig "fertig-produkte" zurück wie möglich.
Nun habe ich grade ein "Nachrichten"-System fertig gestellt, mit dem die Benutzer untereinander Nachrichten verschicken können, welche auch ganz fleissig im betreffenden Zielordner landen. Dann war ich dabei, dort gerade ein "diese Mail wurde schon gelesen, diese Mail noch nicht"-System ein zu bauen (ich hab in der sql-tabelle, wo die mails gespeichert werden ganz einfach ein Feld für "gelesen" rein gehauen, wo dann 1 oder 0 drin steht), bin nun damit durch und dachte mir: Das kann ich ja auch für das Forum so übernehmen.
Wie man sich wohl vorstellen kann, ist das dort nicht ganz so einfach, da für jeden User einzeln gespeichert werden muss, welche Beiträge er gelesen hat und welche nicht. Nun war ich lange am überlegen, wie man das denn umsetzen kann.
Meine Idee wäre, eine extra Foren-Verlauf-Tabelle zu schreiben, wo dann immer gespeichert wird, wer welchen Beitrag wann gelesen hat. Also praktisch mit den Feldern "beitrag-id" und "user-id". Dann brauche ich nur noch schauen, ob ein Eintrag existiert, in dem User und Beitrag übereinstimmen und voila, fertig. Nur erscheint mir das ein wenig... Unelegant.
Hat jemand eine bessere Idee, wie man sowas umsetzen kann, oder am besten schon erfahrung mit sowas? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
ich weiß nicht ob das was ich gleich schreibe sinnvoll ist, aber ich hab mir das auch grade vor 2 minuten einfach so einfallen lassen:
und zwar: du machst zu jedem forenthread eine spalte dazu, WER den schon gelesen hat. dort schreibst du dann (mit komma oda sonstwas getrennt) die user-ids derjenigen die den thread schon gelesen haben rein. und dann machst du einfach ne abfrage
userid LIKE '%$demuserseineid%'
mfg
ps: bitte schlagt mich nicht, falls das kompletter blödsinn ist :D -
syberpsace schrieb:
ich weiß nicht ob das was ich gleich schreibe sinnvoll ist, aber ich hab mir das auch grade vor 2 minuten einfach so einfallen lassen:
und zwar: du machst zu jedem forenthread eine spalte dazu, WER den schon gelesen hat. dort schreibst du dann (mit komma oda sonstwas getrennt) die user-ids derjenigen die den thread schon gelesen haben rein. und dann machst du einfach ne abfrage
userid LIKE '%$demuserseineid%'
mfg
ps: bitte schlagt mich nicht, falls das kompletter blödsinn ist :D
Hm, da würde ich mich fragen, ob das "tabellen-größen"-Technisch nicht eher uneffizient ist. Denn dann müsste ich ja praktisch pro Forenthread einen string rein setzen, dieser ist afaik 1 Byte per Zeichen groß. Wenn man dann anfängt in Dimensionen zu rechnen wie User-ID 55555, nimmt da der Sring schon 5 Byte + 1 Byte für das Trenn-Zeichen weg. Das sind 48 Bit pro gelesenen Thread...
Wenn ich wie in meiner Idee 2 Integer-Werte speicher (UserID, ThreadID) (beides 16 Bit) komme ich auf 32 Bit pro Forenthread... Also gut ein drittel gespart. Oder irre ich da?
EDIT: Ausserdem muss bei sql-datenbanken ja immer die länge eines Strings mit angegeben werden. Bei wachsender Benutzerzahl würde da die spalte ja immer größer werden. Ob sich das so einfach umsetzen lässt? :/
Beitrag zuletzt geändert: 27.7.2009 10:56:10 von nerdinator -
Die ganzen großen Foren Softwares machen es in aller Regel sehr simpel. Die speichern einfach die IDs der Threads und Boards im Cookie und aktualisieren dieses sobald man einen Beitrag gelesen hat bzw. einfach nur herumsurft und ein neuer Thread/Post in der Zwischenzeit erzeugt wurde.
In der DB kann das durchaus schon sehr viel Speicher fressen. -
Wie evil-devil schon sagte, nimm lieber Cookies, da zwar die Regelung über eine Datenbank bei kleinen Foren mit wenigen Usern noch funktioniert, bei großen Communities aber schlicht eine sehr große Datenmenge erzeugt.
Außerdem ist es ja nur mehr eine Komfortfunktion, wenn alo ein User Cookies nicht zulässt, wird er darauf ganz sicher verzichten können. -
Hm, ich kenne viele große Communitys, die das offenbar anders regeln. Denn dort werden mir immer nur die Beiträge angezeigt, welche ich halt noch nicht gelesen habe - und das egal, von welchem Rechner aus ich mich einlogge. So in etwa möchte ich es auch haben.
Mir kam da dann noch eine Idee, womit man den Speicherbedarf reduzieren könnte: Da Forenthreads fortlaufende ID's haben, könnte man das ganze auf binärer Basis lösen. So könnte man die "Tags" für 8 Posts in einem Byte speichern. 0 ungelesen, 1 gelesen. Da mir da aber eine Datenbank als "unzureichend" erscheint, (man muss bei Strings immer eine feste Länge angeben) würde ich mir überlegen, sowas in einer extra datei zu speichern. mit fopen() wird dann der Dateizeiger an den Byte ThreadID modulo 8 oder so verschoben, das Zeichen ausgelesen, in seine bits zerlegt und dann geschaut, ob der thread gelesen ist oder nicht. Oder vielleicht noch besser: man ließt ein mal die Datei für alle angezeigten Threads ein und zerlegt dann das ganze in seine Bits... Klingt mir aber auch recht unelegant. ^^ -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
