Avatar

gelesen-Status, read-status (in german) (Project organisation)

by Auge ⌂, Sunday, November 20, 2016, 15:32 (2707 days ago) @ Micha

Hallo

Wenn ich mir das jetzt so ansehe, bin ich mir diesbezüglich gar nicht mehr so sicher. Es könnte also auch ein … [SUBSELECT] … optimaler sein. In meinem Testforum mit vier Einträgen lässt es sich aber nicht genau verifizieren, sodass ich Dir keine Empfehlung geben kann.

Mit meinem Forum, in dem ich ein paar mehr Testeinträge zur Templateentwicklung drin habe, werde ich auch keine aussagekräftigen Benchmarks erstellen können. Da müssen wir wohl auf Rückmeldungen warten. Optimierungen für nur eventuell vorhandene Performanzbremsen müssen wir IMHO nicht anpacken.

Grundsätzlich:

Auf mehreren Seiten habe ich die Aussage gefunden, dass speziell bei MySQL JOINs zu bevorzugen seien, eben weil der JOIN einmal beim einsammeln der Datensätze ausgeführt wird, wohingegen ein Subselect für jede Ergebniszeile erfolgt. Die Fundstellen sind allerdings auch alle schon einige Jahre alt gewesen.

Ob MySQL in der Hinsicht heutzutage besser optimiert oder auch nicht, kann ich schlicht nicht beurteilen. Zumal ja nicht jede MLF-Installation auf Servern mit (einigermaßen) aktueller Softwarebasis erfolgt. Der JOIN funktioniert jedenfalls, auch wenn er kein boolesches Ergebnis ausgibt (Zahl (INT) oder NULL statt TRUE oder FALSE).

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. ;-)

Hmm, bei leserlich notierten Queries würde ich dir (fast) uneingeschränkt recht geben. Die gegenwärtige Notatation in langen Zeilen mit PHP-Einsprengseln (eben zur Angabe der Tabellen oder Formatanweisungen) finde ich persönlich eben nicht leserlich. Aber das ist Geschmackssache.

Ich habe in den bisher editierten Dateien nur dort Aliase angegeben, wo sie für die neu eingebundene Tabelle notwendig waren. Es betrifft also die neue Tabelle und die Tabelle mlf2_forum_table mit den Einträgen (wegen des Vergleichs). Für die Forumstabelle habe ich das in den geänderten Queries aber auch konsequent durchgezogen. Überall anders habe ich es gelassen, wie es war.

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. ;-)

"Gelesen" ist und bleibt gelesen, bis ein evtl. eingeschalteter Automatismus (den du letzter Tage committet hast) zuschlägt und die Markierung aufhebt. Wird der Refresh-Link benutzt, werden neue Einträge geladen und die Neu-Markierung (der Pfeil bzw. der rote Rand am Thread-Icon) bei bereits gelesenen Einträgen gelöscht.

Das hat, wenn es denn richtig[tm] funktioniert, den weiteren Vorteil, dass ein beim letzten Besuch nicht gelesener Beitrag auch beim nächsten Besuch als ungelesen/neu angezeigt wird. Das nervt mich nämlich in so manchem Forum. Ein Beitrag, den ich jetzt nicht lesen will, finde ich beim nächsten Besuch nur mit Handständen wieder.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

locked
55836 views

Complete thread:

 RSS Feed of thread