Emiel: MySQL - Sehr sehr schwerer Query, ich schaffs nicht alleine

Beitrag lesen

Hey Dedlfix.

Hm okay du hast Recht.
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.

Also ich schneide bevor ich auf den Rest eingehe ein kleines weiteres Thema an. Ich hatte ursprünglich vor das nur der Threadersteller Bilder einbinden darf. Denn ich sehe das Problen folgendem: Ich möchte dem User nicht die Möglichkeit geben Fotos hochzuladen, das sind mir zu hohe Serverkosten, ich möchte das sie nur von extern einen Link setzen können.
Da kommen weiter Probleme auf.
1. Rechtliche - die habe ich aber auch beim Threadersteller, aber es sind dann deutlich weniger rechtliche Probleme die entstehen könnten.
2. Der andere könnte das Bild nach dem Post ändern in ein 4000*9000px Bild. Die Folge ist klar.
3. Die Wartezeit verlängert sich nochmehr.

Also ich stehe da noch sehr im Zwiespalt.

Also ausgehend davon das nur der Threadersteller Bilder einbinden darf, würde ich mit Query 1:
Query 1: Die Thread-Informationen + Bilder + Userinfos
Query 2: Die Post informationen + Userinfos
Query 3: Die Kategorien
holen.

Was hälst du davon? Er darf btw. maximal 10 Bilder einbinden.

»» board_category
»» ##############
»» categoryid subcategoryid categoryname
»» 1          0             Sport
»» 2          1             Handball
»» 3          2             Vereine
»» 4          0             Ernährung

Ich ich sehe das auch als Problemeatisch, ich dachte das würde mit einer einfachen Query funktionieren. 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.
Ich habe aber für mich eine maximal "verschachtelung" von 5 Ebenen festgelegt. Also maximal:
Kategorie 1 -> Kategorie 2 -> Kategorie 3 -> Kategorie 4 -> Kategorie 5

Mein Bauchgefühl rät mir zur Alles-und-dann-selbst-suchen-Variante statt Nested Sets. Die Kategorienanzahl wird sich im niedrigen zweistelligen Bereich bewegen, da ist das vertretbar, wenn man sich auf der anderen Seite den Nested-Sets-Aufwand dazu anschaut.

Siehe oben. Wie sieht dein Bauchgefühl jetzt aus?

In der ON-Klausel eines Joins sollten nur die Verknüpfungsbedingungen stehen. Die Datenmenge einschränkende Bedingungen gehören ins WHERE. Lediglich die für die Verknüpfung relevanten/notwendigen einschränkenden Bedingungen kommen noch mit ins ON. Doch auf den Fall trifft man(/ich) eher selten.

Ich weiß, ich weiß, ich weiß, ich habs beim posten hier aus Faulheit schnell so hingeschrieben um deutlicher zu demonstrieren, was bei dem Wert 1 sein würde.

alert("Danke Dedlfix. Auf Wiedersehen Dedlfix.");