nicht angemeldet
echo $begrüßung;
Ich dachte mir wenn ich daraus 3 oder 4 Queries mache dann habe ich bei 400 zugriffen gleich 1200 I/O Zugriffe in der Datenbank statt ein Drittel oder Viertel. Ich sehe sowas immer sehr sehr kritisch und versuche möglichst wenig Queries zu verwenden.
400 Zugriffe in welcher Zeit? Möglichst wenig Datenbankabfragen kann man erreichen, indem man oft gefragtes Zeug in einem Cache ablegt. Auch für aufwendig zu berechnende Geschichten ist es günstig, das Resultat zu cachen, wenn es danach noch ein paar Mal benötigt wird.
Also ich schneide bevor ich auf den Rest eingehe ein kleines weiteres Thema an.
[Probleme mit Bildern]
Also ich stehe da noch sehr im Zwiespalt.
Aus dem kann ich dich auch nicht rausholen. Ich sehe diese Probleme auch, hab aber kein Rezept dagegen.
Also ausgehend davon das nur der Threadersteller Bilder einbinden darf, würde ich mit Query 1:
Query 1: Die Thread-Informationen + Bilder + Userinfos
Was hälst du davon? Er darf btw. maximal 10 Bilder einbinden.
(hältst - mit zwei t) Die Thread-Information benötigst du unbedingt und nur einmal und nicht so oft wie die Bilder, von denen es 0 bis 10 gibt. Das bekommst du mit einem LEFT JOIN geregelt, also dass auch bei 0 Bildern die Thread-Daten kommen, aber bei mehr als einem Bild hast du die Threaddaten mehr als einmal abgefragt. Was ist nun effektiver, zwei Querys oder ein zweifelhafter Join und unnötig redundante Daten? Eine kleine Messreihe wird die Antwort liefern. Überhaupt ist das Messen der verschiedenen Szenarien besser als theoretische Überlegungen. Auch das Definieren von Indexen kann optimierend wirken und die Kontrolle mit EXPLAIN, ob sie auch verwendet werden, sollte man ebenfalls nicht vergessen.
Du vertust dich leider, die Kategorien gehen mindestens in den 3 wenn nicht sogar 4,5- maybe in a few year 6,7 - stelligen Bereich, alleine weil es die Kategorien in mehreren Sprachen geben wird, d.h. wenn es 300 Kategorien sind - werden daraus 1200 Datensätze usw... Die Abfrage muss wirklich schnell sein.
Am besten messen. Das setzt voraus, dass du beide Szenarien implementierst. Schlimmstenfalls hast du Zeit verbraucht, dabei aber Erfahrung gesammelt. Ist es notwendig, den Kategorienbaum je Sprache extra zu verwalten? Sind die Kategorien andere und/oder anders geschachtelt, wenn die Sprache wechselt? Oder ist der Aufbau der gleiche und du hast das Übersetzungsproblem nicht nur für die Kategorien sondern auch für alles andere und brauchst allein dafür schon einen eigenständigen Übersetzungsmechanismus?
Wie auch immer, die Kategorien werden sich nicht soo häufig ändern, der Nested-Sets-Aufwand wird sich vermutlich rechnen. Man könnte auch alle Pfade einmalig (nach jeder Änderung) vorberechnen. Das ergibt auch nur so viele Datensätze wie Kategorien vorhanden sind. Eine Abfrage darauf ist einfachst und ergibt stets einen Datensatz. Noch schneller wirst du es nur mit Caching hinbekommen.
Wie sieht dein Bauchgefühl jetzt aus?
Genauere Vorgaben lassen meinen Bauch genauer fühlen :-) Was auch immer der rausbekommt: Probier es aus. Selbst wenn ich in einem meiner Projekte mit einem ähnlichen Fall Erfahrung hätte, könnten bei dir mit anderen Eingangsparametern andere Werte rauskommen. Versuch es mit dem geringsten Aufwand zu implementieren. Austauschen gegen etwas (nachgemessen) schnelleres kann man es immer noch. (Kapselung von Funktionalitäten und eine möglichst lose Bindung zwischen ihnen erleichtern solche Refactoring-Prozesse.)
echo "$verabschiedung $name";