SQL: LIMIT in SELECT-Klausel?

[Allrounder]

Hallo zusammen,

gibt es eine Möglichkeit, die Anzahl der zu lesenden Datensätze beim select einzuschränken oder die maximale Anzahl der auszugebenden "Treffer" per Parameter mitzugeben? Habe nichts in der Richtung gefunden.

[Fuerchau]

Ab V5Rx (keine Ahnung seit wann)

select ....
where ...
order ...
fetch first x rows only

[Allrounder]

Hey super! Es funktioniert. Danke Fuerchau. Die Antwort kam ja fast schneller als meine Anfrage :-).

[BenderD]

@Baldur: mit Vorsicht zu genießen - bedeutet ohne order by: gib mir mal x beliebige Sätze und funzt mit GROUP BY nicht so, wie man denkt

Ab V5Rx (keine Ahnung seit wann)

select ....
where ...
order ...
fetch first x rows only

[Fuerchau]

Nur mit "Order by " macht die Anwendung Sinn um z.B. "TOP 10" zu erhalten.
Auch bei "Group by" funktionierts, da ja "order by " erst DANACH erfolgt.

Von der Logik ist dass dann halt wie native, wenn man nach x Reads eben aufhört.
Ich sehe darin absolut kein Risiko.

Übrigens andere SQL-Dialekte setzen das an den Anfang eines Selects:
select top xxx ....

[B.Hauser]

Die allgemeine Empfehlung (der IBM) lautet:
Wenn eine bestimmte Reihenfolge erforderlich ist, MUSS ein Order By angegeben werden!

Anderenfalls könnte der Query Optimizer jeden beliebigen Zugriffsweg verwenden. Deshalb kann auch die Angabe von GROUP BY ohne ORDER BY zu überraschenden Ergebnissen führen.

Wer glaubt, dass der Optimizer durch die Vorgabe einer logischen Datei mit einem bestimmten Zugriffspfad gezwungen werden könnte, diesen Zugriffweg zu verwenden, liegt falsch! Wird dieser Zugriffs-Weg verwendet, ist das Zufall. Der Query Optimizer nimmt aus einer logischen Datei lediglich die Feldauswahl, Satz-Auswahl (Select/Omit) und Join-Informationen und schreibt anschließend das SQL-Statement neu. Dann wird der optimale Zugriffs-Weg über ALLE Zugriffswege (logische Dateien und SQL Indices) ermittelt.

Die Angabe von Order By und Fetch First N rows, ist auch keine Garantie, dass das Ergebnis des Select Statements schneller ausgegeben wird, als ohne Fetch First N rows Angabe. Sehr oft wird ein temporäres Ergebnis gebildet und erst dieses Ergebnis wird sortiert.

Birgitta

[BenderD]

Hallo,

- problematisch wirds spätestens, wenn ich die ersten x Reihen gruppiert haben will, gerade weil der order by erst auf die Ergebnismenge erfolgt! (nachdem der fetch by x Sätzen beendet wurde).
Mit Group by habe ich da schon mehrere inkomplette Gruppensätze bekommen, ohne group by hat es bisher eigentlich immer gestimmt, aber selbst das könnte Zufall sein. Sprich: die Database Engine liefert mir mit einem parallel fetch die ersten x Sätze, wüst aus der Datei rausgewürfelt - und macht dann auf die Ergebnismenge ein ORDER BY
mfg
Meine Empfehlung lautet hier eher auf diesen Quatsch zu verzichten.

Dieter Bender

Nur mit "Order by " macht die Anwendung Sinn um z.B. "TOP 10" zu erhalten.
Auch bei "Group by" funktionierts, da ja "order by " erst DANACH erfolgt.

Von der Logik ist dass dann halt wie native, wenn man nach x Reads eben aufhört.
Ich sehe darin absolut kein Risiko.

Übrigens andere SQL-Dialekte setzen das an den Anfang eines Selects:
select top xxx ....

[Fuerchau]

Das wäre dann aber eine falsches Verständnis des fetch first.
Fetch first sollte erst dann wirken, wenn alle anderen Angaben vorher erledigt sind. Sprich das komplette Ergebnis incl. where, group, having und order und erst danach der fetch first.
Alle anderen Formen der Implementierungen machen für mein Verständnis überhaupt keinen Sinn.
Dies würde auch Birgittas Aussage bestätigen, da der fetch first eben nicht wesentlich schneller wird, da ja eben erst die gesamte Ergebnismenge sortiert werden muss.
Wie sonst sollte ich denn z.B. per SQL die Top 10 einer summierten Menge feststellen ?
In vielen Anwendungen, wie z.B. Windows habe ich sonst auf die Anzahl der Fetch wenig Einfluss. Die Eigenschaft MaxRecords der diversen Zugriffsmethoden wirken leider nicht immer.

Wie hat IBM denn nun implementiert ?

[BenderD]

Hallo Baldur,

der fetch first hat nach meiner Erfahrung ganz ähnliche Macken wie RRN(xxx), das keine Resultsets unterstützt. Es ist schon rein syntaktisch nicht möglich einen Subselect sinnig mit fetch first anzufassen, da der ja garkeine ORDER BY Klausel erlaubt. Aus gutem Grund ist dieser Zinnober auch kein Bestandteil des SQL Standards - und alleine schon deshalb würde ich es nicht verwenden, wenn es Standard werden sollte, ist das Risiko, dass sich das Verhalten ändert, einfach zu groß.

mfg

Dieter Bender

PS: Was die Geschwindigkeit angeht, ist optimize for x rows sicher schärfer, aber auch das geht zuweilen in die falsche Richtung. (Auch zu beobachten beim interaktiven SQL versus Programm; interaktiv optimiert meist für die ersten 20 Sätze, im Programm meist für das komplette ResultSet). Ansonsten ist das für DB2 ohne Belang, da nicht das open auf das ResultSet liest, sondern der fetch, mit dem ich seteurn kann, wie oft und wieviel gelesen wird.

Das wäre dann aber eine falsches Verständnis des fetch first.
Fetch first sollte erst dann wirken, wenn alle anderen Angaben vorher erledigt sind. Sprich das komplette Ergebnis incl. where, group, having und order und erst danach der fetch first.
Alle anderen Formen der Implementierungen machen für mein Verständnis überhaupt keinen Sinn.
Dies würde auch Birgittas Aussage bestätigen, da der fetch first eben nicht wesentlich schneller wird, da ja eben erst die gesamte Ergebnismenge sortiert werden muss.
Wie sonst sollte ich denn z.B. per SQL die Top 10 einer summierten Menge feststellen ?
In vielen Anwendungen, wie z.B. Windows habe ich sonst auf die Anzahl der Fetch wenig Einfluss. Die Eigenschaft MaxRecords der diversen Zugriffsmethoden wirken leider nicht immer.

Wie hat IBM denn nun implementiert ?