Ergebnismenge beschränken mit "LIMIT" oder "TOP"

[Der schöne Günther]

Eine ganz dumme, allgemeine Frage:

Eine SQL-Query lässt sich in ihrer Größe ja beschränken damit nur n Elemente zurückgegeben werden, in den meisten SQL-Dialekten scheint das LIMIT n oder TOP n zu sein.

Angenommen ich möchte die ersten 100 Treffer zurückgeben, aber auch wissen ob da noch mehr war. Sage ich "LIMIT 100" und bekomme weniger als 100 Treffer ist die Sache klar. Aber wie kann ich unterscheiden, wenn ich 100 Treffer bekomme ob es zufällig exakt 100 Treffer waren oder noch mehr?

Als Workaround fällt mir nur ein stattdessen in der Query mit n+1 zu arbeiten, die ersten n Treffer anzuzeigen und wenn die Ergebnismenge nun n+1 Treffer enthält dementsprechend eine Meldung einzublenden.

[Neutral General]

Soweit ich weiß gibt es da in SQL keine Möglichkeit herauszufinden ob nach den 100 noch mehr kommt.
Außer vllt. mit nem Sub-Select mit dem du schaust wie viele Datensätze noch fehlen.

[Christian Seehase]

Moin Günther,

oder Du fragst mit Hilfe von COUNT direkt die Gesamtzahl der Ergebnisse ab.

[Neutral General]

Zitat von Christian Seehase:

Moin Günther,

oder Du fragst mit Hilfe von COUNT direkt die Gesamtzahl der Ergebnisse ab.

Dann muss er aber gruppieren, was evtl nicht erwünscht ist.

[mkinzler]

Oder vorher

[Bernhard Geyer]

Zitat von Der schöne Günther:

Als Workaround fällt mir nur ein stattdessen in der Query mit n+1 zu arbeiten, die ersten n Treffer anzuzeigen und wenn die Ergebnismenge nun n+1 Treffer enthält dementsprechend eine Meldung einzublenden.

Und was spricht dagegen diesen "Workaround" nicht das beste und einfachste Möglichkeit zu nehmen?
Es ist einfach, es ist verständlich und es funktioniert ohne weiter Zusätzliche Implementierung.

[Delphi.Narium]

Zitat von Neutral General:

Zitat von Christian Seehase:

Moin Günther,

oder Du fragst mit Hilfe von COUNT direkt die Gesamtzahl der Ergebnisse ab.

Dann muss er aber gruppieren, was evtl nicht erwünscht ist.

Seit wann muss man bei Count gruppieren?

Select top 100 * from tabelle where irgendwas
Select count(*) As Anzahl from tabelle where irgendwas

Select * from tabelle where irgendwas limit 100
Select count(*) As Anzahl from tabelle where irgendwas

Select * from tabelle where irgendwas and rownum <= 100
Select count(*) As Anzahl from tabelle where irgendwas

Select first 100 * from tabelle where irgendwas
Select count(*) As Anzahl from tabelle where irgendwas

Gruppieren muss man nur, wenn man mehr als die Anzahl zurückbekommen will, bzw. wissen will, wie oft bestimmte Werte vorkommen.

Das ist aber was vollkommen anderes, als eine Einschränkung per Top, Limit, First, Rownum und das Zählen der Sätze, die ggfls. insgesamt geliefert werden könnten.

[himitsu]

LIMIT 101 im Select und im Grid/DataSource dann nochmal auf 100 die Anzeige kürzen.

> in der Anzeige gibt es nur die 100, aber im DataSet mit >100 (ohne DataSet-Filter) sieht man ob es noch mehr gibt.


sowas?

SQL-Code:

Select top 100 count(*) As Anzahl from tabelle where irgendwas

Select count(top 100 *) As Anzahl from tabelle where irgendwas

oder ganz doof
select count(Select top 100 * from tabelle where irgendwas)

aber wo, wenn es auch so geht?

SQL-Code:

Select count(*) As Anzahl from tabelle where irgendwas
-- if Anzahl.AsInteger - Top - Limit > 100 then  // 100=

Select count(*) - :Top - :Limit > 100 As Zuviel from tabelle where irgendwas
-- if Zuviel.AsBoolean then

[jobo]

Zitat von Bernhard Geyer:

Und was spricht dagegen diesen "Workaround" nicht das beste und einfachste Möglichkeit zu nehmen?
Es ist einfach, es ist verständlich und es funktioniert ohne weiter Zusätzliche Implementierung.

Ich denke es spricht nichts dagegen, es war halt die Frage nach dem "was geht noch?".

Da DSG ja seine Anwendung gern recht kundenfreundlich gestaltet, wäre die Frage ja eher, was spricht wofür.

- Ein System, das mit exakten Angaben/Vorgaben arbeitet und entsprechend 100+(es gibt mehr) ausspuckt, nervt dezent, wenn es denn 101 sind oder 102 ..
- Ein System, was die Vorgaben nicht so genau nimmt und gleich die vorhandenen 109 Datensätze ausgibt, wäre cool
- Ein System, das genau 100 ausgibt, mit der Angabe "es gibt einige mehr" für +-25 und es gibt viel mehr für +-50 usw. wäre cool

Geschieht dies Ressourcen schonend, wäre es noch cooler und das ist ja neben dem Programmieraufwand, das einzige Argument, was gegen eine "schicke", "smarte" Lösung spräche. Wenn die Anwendung für so viel smartness 10 Sekunden zum "Rechnen" braucht, wird der Anwender darauf verzichten wollen.

In der Praxis macht es in vielen Fällen keinen Unterschied, ob noch mal ein separater Count mit der gleichen Where Clause abgefragt wird, warum also dann nicht? Bei einer "offenen Buchungsliste" wäre das allerdings dann vermutlich coolness am falschen Platz. Und bei manch "teueren" Abfragen ist man einfach froh, wenn sie halbwegs flott zurückkommen und stellt nicht noch weiter blöde Fragen.

Daneben gibt es noch technische Feinheiten wie Limit 100!=ab da hat sich niemand mehr Arbeit gemacht. Bspw. ..order by..limit 100 wird zumindest dafür sorgen, dass der Server garantiert die vollständige Menge bearbeitet. Gespart ist da also erstmal gar nichts, nur etwas Übertragung halt.

[Neutral General]

Zitat von Delphi.Narium:

Seit wann muss man bei Count gruppieren?

Select top 100 * from tabelle where irgendwas
[...]

Gruppieren muss man nur, wenn man mehr als die Anzahl zurückbekommen will, bzw. wissen will, wie oft bestimmte Werte vorkommen.

Ja super.
Das Problem ist nicht mit einer zweiten Abfrage die wirkliche Anzahl an Datensätzen festzustellen sondern in einer Query 100 Datensätze zu selektieren und anhand DIESES Ergebnisses ableiten zu können ob es noch mehr Daten gibt oder nicht. Und das geht mit Count nur wenn man gruppiert oder das Count (wie ich vorgeschlagen habe) in ein Subselect verlagert.