SQL: LIMIT in SELECT-Klausel?

[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 ?