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

[jobo]

Zitat von Neutral General:

.. 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 ..

Ja, das wäre die Ecke, die ich meinte. Sowas zu machen ist nicht das Problem, code seitig. Die Frage ist, wieviel Ressourcen es kostet.

Und meine Vermutung wäre:
Wenn man bereits eine Komponente einsetzt, die nachladen kann, wäre das vielleicht schonender, als die eine Variante mit Limit plus extra Count und oder Group.

[Delphi.Narium]

Zitat von 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.

Tut mir leid, das verstehe ich nicht, könntest Du das bitte mit einem Beispiel erläutern?

select top 100 * from tabelle where bedingung Kann maximal 100 Sätze liefern.

select Count(*) from tabelle where bedingung liefert die Gesamtzahl der Sätze zur Bedingung.

Ist diese Zahl > 100, so weiß ich, dass ich mit mehr als 100 Sätzen rechnen muss und kann zum ersten Statement einen entsprechenden Hinweis ausgeben, der besagt, dass es zu den 100 Sätzen noch weitere Zahl - 100 Sätze gibt.

Ein Subselect oder eine Gruppierung erscheinen mir nicht erforderlich.

Wo liegt mein Denkfehler?

Die Ursprungsfrage war doch: Wenn ich per Top 100 die Menge einschränke, wie kann ich erfahren, ob es mehr, weniger oder genau 100 Sätze gibt?

Weniger ist klar: Kommt bei Top 100 weniger als 100 heraus, gibt es weniger als 100. Kommen 100 Sätze heraus, so gibt es mindestens 100 Sätze. Das Mehr kann bei 0 bis n liegen.

Mit einem Subselect muss man nur dann arbeiten, wenn man bei der Ermittlung der weiteren, möglichen Ergebnismenge, die bereits erhaltene explizit ausklammern will. Für die Feststellung der Größe einer möglichen Ergebnismenge erscheint mir das nicht erforderlich. Gesamtmenge (Count(*)) minus bereits erhaltener Menge (top 100) = Restmenge.

Anhand einer Datenmenge von select top 100 * from tabelle where bedingung kann ich nicht feststellen, ob es mehr, als die ausgewählte Datenmenge, gibt. Auch durch Count mit oder ohne Gruppierung nicht, ich werde immer mindestens eine weitere Abfrage benötigen.

Oder möchtest Du darauf hinaus, dass das Count quasi schon eine Teilmenge des Ergebnisses ist? Also grob sowas in der Art:

select top 100 *, GesamtanzahlDesMöglichenErgebnisses from tabelle where bedingung

[Neutral General]

Zitat von Delphi.Narium:

Oder möchtest Du darauf hinaus, dass das Count quasi schon eine Teilmenge des Ergebnisses ist? Also grob sowas in der Art:

select top 100 *, GesamtanzahlDesMöglichenErgebnisses from tabelle where bedingung

Genau das.

Code:

select top 100 
   *, 
   (select count(*) from tabelle where bedingung) as alle
from tabelle where bedingung

Dass es in 2 Abfragen machbar ist, ist klar. Aber Der schöne Günther hat ja nach einer Möglichkeit gefragt wie er es mit einer Abfrage erkennen/lösen kann.

[p80286]

Mir ist die Aufgabenstellung nicht so ganz klar. Irgendwie klingt das nach ich hab nur 100 EUR aber vielleicht gebe ich noch mehr aus.
So zu denken ist für Menschen ganz normal, die meisten Programm sind nicht so indifferent.

Gruß
K-H

[Der schöne Günther]

Vielen Dank erst einmal für all die Antworten, das ist alles sehr hilfreich!

Zitat von p80286:

Mir ist die Aufgabenstellung nicht so ganz klar.

Ich denke die Aufgabenstellung ist ziemlich klar: Eine Query liefert u.U. viele Treffer. Es macht keinen Sinn alle abzuholen und zu verarbeiten. Ich möchte zuverlässig wissen ob das Ergebnis zufällig genau 100 Elemente enthält oder mehr.

Wenn dem Benutzer die 100 Treffer nicht reichen muss er genauer suchen
Mehr will ich gar nicht. Das ist ja auch nichts ungewöhnliches, so etwas sieht man ja überall.

[himitsu]

Falls das DBSM es nicht gut erkennt oder man dieses "immer gleiche" SubSelect nicht in jeder Zeile ausgeführt haben will,
oder man es im HauptSelect nicht drin stehen haben will, dann vielleicht in einen JOIN verschieben.

[Neumann]

Man könnte es in eine Procedure (Syntax Firebird) verpacken:

create or alter procedure test (
y integer)

returns (
anzahl integer;
p1 integer usw
)
as
begin

select count(*) from table where f1=:y into anzahl;

for select first 100 f1,f2,f3,...fn. from table where f1=:y into :p1,:p2,:p3,.. :pn

do suspend;
end;

Dann hat man in jedem Datensatz die Anzahl wenn man die Procedure mit einer Query abfragt.

[Der schöne Günther]

Dafür ist mein SQL nicht gut genug, ich verstehe kein bisschen.

[Lemmy]

Zitat von Der schöne Günther:

Dafür ist mein SQL nicht gut genug, ich verstehe kein bisschen.

und was genau ist jetzt daran schädlich / schlimm / Whatever wenn man das in 2 Abfragen nacheinander ausführt?

Grüße

[Der schöne Günther]

Ein

Code:

SELECT COUNT(*) where Bedingung

kann ich mir nicht leisten, die Bedingung ist komplex.

Das dauert so lange dass man sich erst einmal einen Kaffee holen kann. Zumindest wenn in der Datenbank schon ein paar Millionen Datensätze stecken.