nicht angemeldet
Salut!
Mein Beitrag sollte Dir eigentlich sagen, dass ein CAST im SQL-Dialekt von MySQL gar nicht notwendig ist.
Hmm und äh und *die Augen reib*.(Ich hatte den Beitrag vorher nur überflogen) Ich hab das CAST Statement noch mal aus dem Code rausgenommen - und siehe da: Genau wie du sagst (surprise :) ), funktioniert genauso.. Ich würd ja gerne wissen was ich da ursprünglich verknorzt hatte - denn ausprobiert hab ichs mehrfach... problemblind? Hmm. Auf jeden Fall eine schöne Sache, so sieht der Code fürs Auge schon mal angenehmer aus. (hoffentlich hat Ekki deinen Post auch gelesen :) )
a) allein das ist schon teuer, weil HAVING erst auf die gesamte Ergebnismenge angewandt wird und nicht vorher einschränkend wirken kann.
Ja das hab ich mir gedacht. Bei nur einem Suchbegriff kann ich diesen mit WHERE realisieren (mache ich in dem Falle also auch), aber bei mehreren schliessen sich die Suchergebnisse natürlich gegenseitig aus und bspw. eine OR Verknüpfung führt nicht zum selben Resultat..
b) Bist Du Dir ganz sicher, dass die Werte in den Spalten
(...)
zu gleicher Id in der Tabelle stichwortliste alle gleich sind?
Ja. Die Medienliste ist eine reine Auflistung aller vorhandenen Medien mit deren Eigenschaften als Spalten. id<=>medium ist dabei eine 1:1 Beziehung, eine Id ist also eindeutig für ein einziges Medium und damit auch für jeden zugehörigen Spaltenwert.
also zB:
ID | Titel | Untertitel | ...
-------------------------------------------------------------------------
12 | Der bla von bla | Kolumbus und die Entdeckung Amerikas
234 | SQL verstehen | Aufbau, Syntax & Funktionsweise
... etc
Dies im Gegensatz zur stichwortliste, wo beliebig viele Einträge mit einer bestimmten id und einem zugehörigen Stichwort stehen können
ID | Stichwort
--------------------------
12 | bla
12 | von
12 | Kolumbus
12 | Amerikas
234 | SQL
234 | verstehen
234 | Aufbau
... etc
Wenn nein, liefert diese Abfrage in den von mir genannten Spalten nicht vorhersagbare Werte.
Diesen "Stolperstein" muss ich mir merken. Welchen Wert wählt mysql denn aus in einem solchen Fall? Oder geht das zu tief in die interne Funktionsweise rein? (Auch ein auf den ersten Blick chaotisches Verhalten muss schliesslich, wenn auf rein logischen Vorgängen/Beziehungen beruhend ein vorhersagbares Resultat haben (ausser wenns dann timevariant ist :) ))
Momentan wäre es daher hilfreich, ein paar Datensätze beider Tabellen zur Verfügung zu haben, um das Verhalten nachvollziehen zu können und zielführende Hinweise geben zu können.
Reicht dir das obige Beispiel? Was hältst du vom allgemeinen Aufbau der Datenbank? (Dieser ist mir zwar grundsätzlich vorgegeben, ich könnte höchstens Anregungen weiterleiten)
Berechnete Spalten für die Sortierung sind teuer und bei Dir müssen sie für alle Datensätze berechnet werden, weil Du die Anzahl der Datensätze nicht durch eine "echte" WHERE-Klausel einschränkst. Deine WHERE-Klausel ist nur ein implizite Join-Schreibweise. Kann man zuerst die Datensatzanzahl einschränken, die betrachtet werden muss und nur für diese die berechneten Spalten berechnen lassen, so kann dies deutlichen Performancegewinn bringen.
Ich berechne vorher noch mit PHP die Gesamtanzahl der Resultate (natürlich ohne Sortierung). Bei dieser Gelegenheit könnte ich die Id-Werte der Resultate abspeichern und dann für die eigentliche Resultatabfrage verwenden, zB mit einem riesigen IN() Statement - Wäre dieses trotz dessen Grösse allenfalls schneller?
Freundliche Grüsse
stewe