Forum Neue Beiträge?

eternitysoft

Mitglied
Hi also wollte mir mal nen kleines Forum coden (ja ist gibt genügend naund hat schon seine Gründe^^)
Und mache mir gerade Gedanke dadrüber wie man am besten das mit den Neuen Beiträgen realisiert hatte folgende idee

für die Hauptseite wo die Foren aufgelistet werden
die Tabelle:

Code:
 id | Name | desc | datum | sort
so am anfang der Hauptseite wird dann in einem Cookie die aktuelle Uhrzeit mit dem Datum gespeichert wenn jemand ein Thema schreibt wird dann im feld datum das Datum gespeichert so das man dann auf der Hauptseite dann abfragen kann ob das Datum im Cookie das im Forum endspricht bzw älter ist wenn ja dann eben neuer Beitrag so problem ist irgendwie muss ich dann noch abfragen ob er es dann gelesen hat aber wie?oder gibt es eine besser möglichkeit
in einer Db das zu speichern dürfte viel zu groß werden

hoffe das ihr mir hier helfen könnt
mfg
et
 
Arbeitest Du mit Usern oder darf da jeder schreiben wie er lustig ist?

Ich arbeite mit Usern und bei mir laeuft das wie folgt:
Es gibt eine Tabelle namens threadvisits.
Dort wird die ThreadID zusammen mit der UserID und dem Timestamp des letzten Besuches im angegebenen Thread gespeichert.
Bei der Darstellung der Kategorien/Threads wird nun geprueft ob es ein Post gibt welches nach dem letzten Besuch geschrieben wurde und dann dementsprechend ein Bild angezeigt welches symbolisiert ob es nun neue Posts gibt oder nicht.
 
ich arbeite mit usern wenn ich es richtig verstanden hab so

tabelle:

Code:
tid | uid | datum
PHP:
$result=mysql_query("
					 SELECT 
    		    			* 
					 FROM 
    		    		   threadvisits
					WHERE 
    		        		  tid ='".$tid."'
					AND
  				    	  uid ='".$uid."' 	      
					" );
while($row = mysql_fetch_assoc($result))
	{	
	  $thread_date = $row['datum'];
	}

if ($lastvisit <= $thread_date)
{
 //Neu
}
else
{
 //alt
}

aber ist das nicht sehr speicherverbrauchend bei 1000 Usern und threads ?
 
Die Tabelle ist ja recht klein daher haelt sich das eigentlich in Grenzen.
Und ist meines Erachtens nach die beste Moeglichkeit festzustellen ob es neue Threads gibt.
Cookies find ich da nicht so toll fuer.
 
Die schonenste, wenn auch nicht verlässlichste Methode ist CSS:-)

Das Pseudoformat a:visited gilt für Links, welche ein User schon mal besucht hat.
Wenn du deine Forennavigation so gestaltest, dass du nicht auf Themen, sondern auf Beiträge verlinkst, solltest du auf diesem Weg dem User immer signalisieren können, was er schon gelesen hat :)
 
Sven Mintel hat gesagt.:
Die schonenste, wenn auch nicht verlässlichste Methode ist CSS:-)

Das Pseudoformat a:visited gilt für Links, welche ein User schon mal besucht hat.
Wenn du deine Forennavigation so gestaltest, dass du nicht auf Themen, sondern auf Beiträge verlinkst, solltest du auf diesem Weg dem User immer signalisieren können, was er schon gelesen hat :)
Der Nachteil dabei ist, dass dies wirklich nur in der Threadliste funktioniert.
Wenn man wie hier, oder in meinem Forum, auch in der Kategorienliste sehen will ob es neue Posts gibt ist wohl meine Variante die meiner Meinung nach optimale Loesung.
Sie funktioniert ohne Cookies und die Tabelle waechst aufgrund kleiner Variablen (2 mal INT(8) und ein Timestamp) nicht in's Unermessliche.
 
Naja.. ich hab bspw. hier sicher schon eine Menge Themen gelesen, ein paar 10.000'e bestimmt....und ich bin nur einer.
Da den Besuch jedes Einzelnen in einer DB zu vermerken....wenn die Tabelle da nicht in allerkürzester Zeit gigantische Ausmasse annimt, weiss ich ja nicht :eek:

Wenn das bei dir nur in der Threadliste funktioniert, dann wird das daran liegen, dass du die Links unterschiedlich angibst.
 
Naja, wenn der Link ganz normal auf die Kategorie verweist ist doch eigentlich klar, dass dieser als besucht gezaehlt wird sobald der einmal angeklickt wurde.
Man wechselt ja dort nun in die entsprechende Kategorie, und nicht gleich zum Post.
Und die PostID anzugeben um dann zur Kategorie zu wechseln wuerde wohl, je nach DB-Design, ein paar unschoene Queries hervorrufen.
Bei mir saehe das z.B. so aus:
1. PostID wird uebergeben, Post aus der DB holen
2. Wenn Post ein ThreadOpener ist, weiter bei 4.
3. Mittels der ThreadID den ThreadOpener aus der DB holen
4. Mittels CategoryID die Kategorie aus der DB holen
5. Falls in eine Subkategorie gewechselt werden soll, weiter bei 7.
6. Mittels TopLevelCategory die Top-Level-Kategorie aus der DB holen
7. Darstellen

Das waeren dann also 2 bis 4 Queries.
 
Wenn man bei deinem DB-Design anhand der PostID nicht mittels eines Queries sowohl Category,als auch Threadersteller ermitteln kann, dann ist dein DB-Designnicht so doll... abgesehen davonglaube ich nichtmal, dass man diese 2-4 Queries bei dir braucht, denn der Bezug von PostID zu den anderen Informationen muss sich ja herstellen lassen, sonst würdest du es auch nicht mit undendlich vielen Queries hinbekommen.
 
Von einem Post innerhalb eines Threads, also nicht dem Thread-Opener kann ich nicht direkt die Kategorie ableiten, dafuer muss ich ueber den Thread-Opener gehen.

Meine Tabellen dafuer sehen wie folgt aus:
forum_categories
id (INT)
category (VARCHAR)
toplevelcategory (INT)

forum_posts
id (INT)
title (VARCHAR)
text (LONGTEXT)
threadid (INT)
categoryid (INT)
userid (INT)
postdate (TIMESTAMP)
closed (INT)

Zur Kategorien-Tabelle:
Wenn die Kategorie eine Top-Level-Kategorie ist, dann ist toplevelcategory=0, ansonsten hat ist dort die ID der Top-Level-Kategorie enthalten. Die Tabelle bezieht sich also in diesem Punkt auf sich selbst.

Zur Post-Tabelle:
title ist nur beim Thread-Opener belegt, die einzelnen Posts haben keinen Titel.
threadid ist nur bei Folgeposts belegt, diese zeigen auf die ID des Thread-Openers.
categoryid ist nur beim Thread-Opener gefuellt, die Posts sind ohne categoryid.
 
Zurück