Hallo dedlfix,
Doch. Having arbeitet auf der Ergebnismenge, die die SELECT-Klausel erzeugt hat. In der Abarbeitung liegt SELECT zwischen GROUP BY und HAVING.
Nein, da wirfst du Sachen durcheinander.
Ja, HAVING
arbeitet auf dem Result Set. Jedoch nicht auf dem via SELECT
erzeugten, sondern auf dem Result-Set vor dem auswerten der Spaltenliste - die wird nämlich zuletzt ausgewertet. Standard-gerecht wird ein SELECT
-Statement nach diesem Schema ausgewertet:
- Zuerst wird ein Produkt aller Tabellen in der
FROM
-Klausel erstellt - Danach wird die
WHERE
-Klausel ausgewertet, um Zeilen zu entfernen, die den Filter-Bedingungen nicht entsprechen - Danach werden die Gruppen wie im
GROUP BY
definiert gebildet - Danach werden die Gruppen entfernt, die nicht den Filter-Bedingungen in der
HAVING
-Klausel entsprechen - Danach werden die Ausdrücke in der
SELECT
-Klausel ausgewertet - Danach werden doppelte Reihen entfernt, die auf die
DISTINCT
-Klausel passen - Danach wird die Ergebnismenge durch ein eventuelles
UNION
zusammengeführt mit den anderen Subqueries - Zuletzt werden die Zeilen sortiert wie im
ORDER BY
definiert
Natürlich gehen die DBMSe ggfls Abkürzungen, etwa beim auswerten der WHERE
-Klausel (die muss nicht erst auf dem vollständigen Produkt passieren), aber es zeigt klar warum welcher Ausdruck wo sichtbar oder nicht sichtbar ist.
Ich habe keine Ahnung, ob der Zettelkasten anders handelt. In PostgreSQL ist das jedoch auch so umgesetzt. Ausdrücke aus der column list im HAVING
referenzieren ist nicht möglich.
LG,
CK