gelesen-Status, read-status (in german) (Project organisation)
Hallo,
Genau. Über ein JOIN würde ich es lösen, da das vermutlich schnelle ist, als die doppelte Abfrage.
Wenn ich auf Subqueries setze, kann ich Statuswerte erzeugen (ja = 1, nein = 0), muss dafür aber einige Vorbereitungen treffen.
Wenn ich mir das jetzt so ansehe, bin ich mir diesbezüglich gar nicht mehr so sicher. Es könnte also auch ein:
... edit_key, IF ((SELECT TRUE FROM mlf2_read_entries WHERE mlf2_read_entries.posting_id = ft.id AND mlf2_read_entries.user_id = 1) = TRUE, TRUE, FALSE) AS `user_read` FROM mlf2_entries AS ft LEFT JOIN mlf2_entries_cache AS ct ...
optimaler sein. In meinem Testforum mit vier Einträgen lässt es sich aber nicht genau verifizieren, sodass ich Dir keine Empfehlung geben kann. Welche weiteren Vorbereitungen noch nötig wären, weiß ich nicht. Auf die schnelle sollte die zusätzliche Zeile doch reichen, oder?
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?
Ich _persönlich_ würde drauf verzichten, da es zwar kürzer aber gleichzeitig auch schwerer zu lesen ist. Im Moment ist sofort ersichtlich, aus welcher Tabelle der Wert kommt, dies würde nachher verloren gehen. Grundsätzlich ist es mir aver egal, da wir diesen SQL ja vermutlich nicht pausenlos anfassen werden.
das setzen der Klasse "read"
Durch die Zusätzliche Abfrage des read-Status wird ein weiteres Feld erzeugt, welches im Idealfall boolesch ist. Dieses steht dann automatisch im Template zur Verfügung. Bei meinem Vorschlag wäre dies also das Feld user_read
. Das sollte daher einfach sein, würde ich meinen.
und das Verhalten der Refresh-Funktion (mit der alles begonnen hat) anzupassen.
Wobei ich hier gar nicht mehr weiß, für was Ihr Euch entschieden habt.
Viele Grüße
Micha
--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences