gelesen-Status, read-status (in german) (Project organisation)
Hallo Milo
Das heißt, diese Information kann – z.B. mit einem Subquery, der je nach Status 0 oder 1 zurückgibt oder über einen Join – direkt an das Posting gebunden werden.
Genau. Über ein JOIN würde ich es lösen, da das vermutlich schnelle ist, als die doppelte Abfrage.
Ich habe mir die Abfrage aus der thread.inc.php
genommen – die entsprechenden Abfragen in entry.inc.php
, rss.inc.php
, etc. sollten ja analog aussehen – und habe etwas herumexperimentiert. Wenn ich auf Subqueries setze, kann ich Statuswerte erzeugen (ja = 1, nein = 0), muss dafür aber einige Vorbereitungen treffen. Die Performancefalle wegen der Ausführung des Subqueries in jeder Ergebniszeile bei größeren Threads lasse ich mal gleich außen vor. Mit einem LEFT JOIN
hingegen muss ich nur die Benutzer-ID bei Bedarf auf 0
setzen und den kleinen Umweg über Wert oder NULL gehen.
Ich würde auch gern Aliase für die Tabellennamen einbauen, um die Anzahl der Stellen, an denen die Namen mit PHP-Code eingefügt werden, zu verringern. Hältst du das für sinnvoll?
SELECT …, edit_key, rst.user_id AS req_user FROM mlf2_entries AS ft LEFT JOIN mlf2_entries_cache AS ct ON ct.cache_id = ft.id LEFT JOIN mlf2_userdata AS ut ON ut.user_id = ft.user_id LEFT JOIN mlf2_userdata_cache AS uct ON uct.cache_id = ut.user_id LEFT JOIN mlf2_read_entries AS rst ON rst.posting_id = ft.id AND rst.user_id = ". intval($user_id) ." WHERE tid = ". intval($thread_id) ." ORDER BY ft.time ASC";
So werde ich das (bei Widerspruch ausnehmlich der Aliase) einbauen und dann bleibt noch die Aufgabe, das setzen der Klasse "read" und das Verhalten der Refresh-Funktion (mit der alles begonnen hat) anzupassen.
Tschö, Auge
--
Trenne niemals Müll, denn er hat nur eine Silbe!