Rolf B: Extreme Performance-Unterschiede zwischen MariaDB und MySQL?

Beitrag lesen

Hallo Felix,

wenn Du die Zuordnungen in PHP löst, dann musst Du trotzdem aufpassen. Es darf nicht passieren, dass Du nachher pro Result-Row eine oder mehrere Extraqueries absetzt. Das wäre bei 500 Rows viel zu langsam.

Die Query wird dadurch verkompliziert, dass die DB hoch normalisiert zu sein scheint. Das ist nicht immer gut. Eine Query über 9 Tabellen ist schon heftig.

Beispiel: Welche Users gibt es, außer Staff? Was sind die Extra-Attribute in Staff? Wenn es nur wenige Attribute sind, lohnt es sich, Staff in Users zu integrieren und ein Attribut user_type einzuführen. Das ist dann nicht Normalform, aber performanter. Denormalisierung ist oft die Schmiere im DB Getriebe. Eine noch normalisierte DB braucht viel Cache, damit die Joins nicht in die Knie gehen. Ähnliches gilt für students und people. Welche Leute gibt es noch, außer Schülern? Besteht eine Relation zwischen people und users? Kann es sinnvoll sein, auch hier zusammen zu legen? Ok, es mag zu spät dafür sein, weil zuviel Legacy Code da ist.

Es scheint auch einen Modellfehler zu geben. students.form ist ein Attribut, das nicht nur vom Schüler abhängt, sondern auch vom Datum. Oder ist das nur der Zug, in dem der Schüler ist? Aber auch der mag sich ändern; es mag Gründe geben warum ein Schüler von der 5a in die 6b wechselt (z.B. je nach Wahl der 2. Fremdsprache, oder weil die a ihn mobbt). D.h. die Angabe der Klasse (form) gehört an die Kursbuchung. Schüler Willi bucht 2019/20 den Kurs Latein-3 und gehört dann der 8c an.

Ist form ein Attribut des Schülers, bekommst Du Probleme beim Abruf von Daten des Vorjahres. Willi ist mittlerweile in der 9c, aber wenn Du Kurse vom letzten Schuljahr abfragst, war er noch in der 8c. Du kannst auch nicht einfach 1 abziehen, weil Willi ja nicht in der 9c sein muss. Er kann auch sitzen geblieben oder gesprungen sein.

Was soll die Query eigentlich liefern? Prüfungen ab dem 22.9.19 und die zugehörigen Schüler, und zwar für Kurse, wo ein Lehrer mit leerem user-login existiert. Für den geprüften Kurs noch das letzte Subject vor dem Prüfungsdatum - hä? Wofür steht eine Row in einem Kurs, und was für ein Datum ist schedule? Was ist das subject eines Kurses? Deutsch? Oder "Gedichtinterpretation" - das hätte ich aber eher an der Lesson vermutet. Ich bin auch nicht sicher, dass Du den DISTINCT bei dieser Subquery brauchst, du suchst doch den Kurseintrag mit dem höchsten Schedule-Wert vor der Prüfung, und da gibt's doch vermutlich nur einen, oder? Ich hab ja keine Ahnung was Du in courses genau drin hast 😉

Und dann werden noch die Lehrer hinzugemixt, die zum Kurs eine Lektion erteilt haben, und zwar nur die, die am oder jüngstes vor dem Prüfungsdatum stattfand (hier ist <=, beim anderen Subselect ist <, ist das korrekt?)

Das sieht nach einem SEHR ungewöhnlichen fachlichen Szenario aus. Wenn Du hier Hilfestellung bei einer besseren Query willst, müsstest Du etwas mehr davon erzählen. Das mag dann aber zu viel über eure Schulinterna enthalten.

Es sieht jedenfalls danach aus, als ob die Lehrer ohne Login der Kern der Sache sind. Oder gehört da eigentlich eine konkrete Login-ID hin und du hast sie weganonymisiert?

Rolf

--
sumpsi - posui - clusi