View Full Version : SQL: Sortierung individuell nach einer Werte-Tabelle
Wo kann man denn das nachlesen, wie das mit den Ausdrücken im ORDER BY funktioniert?
SQL-Reference, Stichwort "Order By Clause".
Das selbe gilt übrigens auch bei "Group by", wobei hier der Unterschied besteht, dass der Ausdruck identisch im Select stehen muss.
Deshalb ist es gedanklich häufig einfacher einen
"select * from (select f1, f2, Ausdruck as f3....) Hugo order by f1, f2, f3"
zu kodieren auch wenn es im Endeffekt egal ist.
Je nach Dialekt und AS/400-Version ist ein Ausdruck in Order By nur erlaubt, wenn dieser auch im Select steht.
Ein Order-Feld, das nicht im Select steht ist erst seit V5R3 erlaubt und andere Dialekte erlauben es ggf. gar nicht.
Ich weiß auch nicht, wie SQL nun reagiert wenn ich folgendes mache (keine Lust zum Probieren):
select f1, f2, f3 from myfile
order by f1, 2, 10
Mit "2" wird das 2. Feld der Select-Liste benannt, mit "10" müsste nun ein Ausdruck angenommen werden da Feld 10 nicht existiert.
Man kann es einfacher machen, indem man alles in einem Statement zusammenfasst.
... aber mein Statement war sicher nicht falsch. Probier's aus wenn Du es nicht glaubst.
Die Sortierung Kunden-Nr. erfolgt nur bei z.B. KundenNr = 50 alles andere wird ignoriert.
Man könnte die Case-Anweisung sogar noch weiter treiben, in dem man bei untershiedlichen Kunden-Nr. jeweils nach unterschiedlichen Spalten sortiert (vorausgesetzt diese Spalten sind vom Datentyp her kompatibel - vielleicht gilt diese Beschränkung aber nicht mehr im neuen Release).
z.B.
Order By Case When KndNr in (50, 3, 18) Then KndNr
When KndNr in (23, 17, 5) Then ArtikelNr
Else AnderesFeld End
Birgitta
Diese Idee fände ich am Besten, sie funktioniert aber nicht so, wie ich es brauche. Wenn ich das so mache, dann werden die Kundennummern einfach wieder aufsteigend sortiert (habe es eben getestet). Ich brauche sie aber nicht aufsteigend, sondern in meiner ganz individuellen Reihenfolge.
Gruß
Artur
Ich weiß auch nicht, wie SQL nun reagiert wenn ich folgendes mache (keine Lust zum Probieren):
select f1, f2, f3 from myfile
order by f1, 2, 10
Mit "2" wird das 2. Feld der Select-Liste benannt, mit "10" müsste nun ein Ausdruck angenommen werden da Feld 10 nicht existiert.
Habe es eben ausprobiert. Es funktioniert nicht. SQL "denkt" bei den Zahlen immer an Spaltennummern. Sobald die "10" erkannt wird, bricht die Verarbeitung mit Fehler [SQL0125] ab.
Man kann aber auch wie folgt nach den unterschiedlichen Kunden-Nr. sortieren (dabei muss man nur ein bisschen tippen):
select kdnr, name, ort, umsatz
from kundenstamm
where kdnr in (50, 1, 10, 8, 60, 5)
order by Case When Kdnr = 50 Then KdNr End,
Case When KdNr = 1 Then KdNr End,
Case When KdNr = 10 Then KdNr End,
Case When KdNr = 8 Then KdNr End,
Case When KdNr = 60 Then KdNr End,
Case When KdNr = 5 Then KdNr End;
Birgitta
Diese Variante funktioniert in meinem Sinne. Habe es eben getestet. Die Sätze kommen wirklich in der Reihenfolge 50, 1, 10, 8, 60, 5.
Das ergibt sich doch im Ausdruck, da du doch keine neue Sortierung vorgibst als die Kunden-Nr.!
Die Reihenfolge im In-Ausdruck spielt überhaupt keine Rolle. Hier wird eine sequentielle Prüfung der Werte vorgenommen.
Was diesen Ausdruck angeht:
order by Case When Kdnr = 50 Then KdNr End,
Case When KdNr = 1 Then KdNr End, ...
So ist er im Moment wohl noch richtig, da der Default beim "Order By" "NULLS LAST" ist und dieses Verhalten nicht beeinflusst werden kann. Dies könnte mit dem nächsten Release geändert werden, dann stimmt der Sort nicht mehr. Bei OLAP-Funktionen ist die Angabe schon möglich.
Und schon wieder falsch:
Wenn ich das kurz korrigieren darf:)?
order by Case Kdnr
when = 50 Then 1
When 1 Then 2
When 10 Then 3
When 8 Then 4
When 60 Then 5
When 5 Then 6 End
Diese Variante funktioniert auch in meinem Sinne (gerade getestet). Die Sätze kommen in der Reihenfolge 50, 1, 10, 8, 60, 5
So ist er im Moment wohl noch richtig, da der Default beim "Order By" "NULLS LAST" ist und dieses Verhalten nicht beeinflusst werden kann. Dies könnte mit dem nächsten Release geändert werden, dann stimmt der Sort nicht mehr. Bei OLAP-Funktionen ist die Angabe schon möglich.
Das glaube ich kaum, da sonst u.a. die Sortierung beim Multi-dimensionalen Grouping nicht mehr funktionieren würde. Da wird davon ausgegangen, dass in der "Gruppen-Wechsel Spalte" für die Summen-Zeile NULL steht, wodurch die Summe ans Ende sortiert wird.
Die Aggregat-Funktion GROUPING würde ebenfalls nicht funktionieren.
Ähnliche Probleme würden bei den Rekursiven Abfragen und hierarchischen Query-Anweisungen auftreten.
OLAP-Funktionen haben einen individuellen Order By.
Auf alle Fälle gehe ich nicht davon aus, dass der DEFAULT geändert wird. ggf. kann durch eine entsprechende Sortierreihenfolge das Verhalten beeinflusst werden.
Birgitta
Das ergibt sich doch im Ausdruck, da du doch keine neue Sortierung vorgibst als die Kunden-Nr.!
Die Reihenfolge im In-Ausdruck spielt überhaupt keine Rolle. Hier wird eine sequentielle Prüfung der Werte vorgenommen.
Was diesen Ausdruck angeht:
order by Case When Kdnr = 50 Then KdNr End,
Case When KdNr = 1 Then KdNr End, ...
So ist er im Moment wohl noch richtig, da der Default beim "Order By" "NULLS LAST" ist und dieses Verhalten nicht beeinflusst werden kann. Dies könnte mit dem nächsten Release geändert werden, dann stimmt der Sort nicht mehr. Bei OLAP-Funktionen ist die Angabe schon möglich.
... derANSI Standard erlaubt durchaus Sortierungen nach abgeleiteten Feldern (Ausdrücken) und (idiotischerweise) nach Feldern, die nicht im Resultset enthalten sind. Die Behandlung der Nullvalues ist nur geregelt, wenn die entsprechende Clause (Null first oder Null last) das regelt, ansonsten ist das Implementierungs spezifisch und sollte vermieden werden.
Dass diese Sortierung nach einem Case Ausdruck Käse ist, erkennt man daran, dass bei neu dazu kommenden Artrikeln SQL Statements angepasst werden müssen (order by in Views ist nicht ANSI konform und kann sich mithin künftig ändern). Ich bezweifle auch stark, dass ein Order by nach einem Case Konstrukt im richtigen Leben für entsprechende Datenmengen vernünftig skaliert und mit einem Index ausreichend gestützt werden kann.
Summa Summarum rate ich von diesem Ansatz ernstlich ab!!!
D*B