dedlfix: concat(...) AS neuer_feldname nicht im select-Teil?

Beitrag lesen

Hi!

FROM, WHERE, GROUP BY, SELECT (1), HAVING, ORDER BY, SELECT (2)
Select wird 2mal ausgewertet, da für HAVING die having-Werte bekannt sein müssen (im HAVING können die Aliase benutzt werden).

Im GROUP BY und ORDER BY können auch Aliase verwendet werden. Für diese beiden Klauseln kann sogar die Nummer der Spalte (wie in SELECT angegeben) genommen werden. Die Nummer muss man nur später anpassen, wenn sich die Reihenfolge verändert.

Bei der Ausführungsreihenfolge würde ich eher wie folgt plädieren:

FROM, WHERE, SELECT (1), GROUP BY, SELECT (2), HAVING, ORDER BY, LIMIT

(Die nachfolgende Ausführung ist meine Interpretation, auch wenn ich wie ein Fakt formuliere.) Das erste Select liefert mindestens die Aliasnamen für die Gruppierung, das zweite berechnet die Aggregatfunktionen. In einem der beiden findet auch die Berechnung der anderen Spalten statt, was aber nur für MySQL gilt, denn andere DBMSe gestatten nur gruppierte Spalten und Aggregatfunktionen. Kommt keine GROUP-BY-Klausel zum Einsatz, braucht es nur ein SELECT. ORDER BY muss sich auf die Select-Ergebnisse (nicht nur die Aliase) beziehen können, deswegen die Anordnung nach den SELECTs. Zum HAVING schreibt das MySQL-Handbuch: "The HAVING clause is applied nearly last, just before items are sent to the client, with no optimization. (LIMIT is applied after HAVING.)" Demnach müsste es eigentlich nach dem ORDER BY kommen, aber wenn die Ergebnismenge noch eingeschränkt wird, halte ich es eher für sinnvoll, die reduzierte Menge zu sortieren.

Lo!