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

Delphi-Quellcode:

n

Elemente zurückgegeben werden, in den meisten SQL-Dialekten scheint das

Delphi-Quellcode:

LIMIT n

oder

Delphi-Quellcode:

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

Delphi-Quellcode:

n+1

zu arbeiten, die ersten

Delphi-Quellcode:

n

Treffer anzuzeigen und wenn die Ergebnismenge nun

Delphi-Quellcode:

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:

Zitat von Christian Seehase (Beitrag 1394162)

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:

Zitat von Der schöne Günther (Beitrag 1394160)

Als Workaround fällt mir nur ein stattdessen in der Query mit

Delphi-Quellcode:

n+1

zu arbeiten, die ersten

Delphi-Quellcode:

n

Treffer anzuzeigen und wenn die Ergebnismenge nun

Delphi-Quellcode:

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:

Zitat von Neutral General (Beitrag 1394163)

Zitat:

Zitat von Christian Seehase (Beitrag 1394162)

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?

SQL-Code:

Select top 100 * from tabelle where irgendwas

SQL-Code:

Select count(*) As Anzahl from tabelle where irgendwas

SQL-Code:

Select * from tabelle where irgendwas limit 100

SQL-Code:

Select count(*) As Anzahl from tabelle where irgendwas

SQL-Code:

Select * from tabelle where irgendwas and rownum <= 100

SQL-Code:

Select count(*) As Anzahl from tabelle where irgendwas

SQL-Code:

Select first 100 * from tabelle where irgendwas

SQL-Code:

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

SQL-Code:

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:

Zitat von Bernhard Geyer (Beitrag 1394167)

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:

Zitat von Delphi.Narium (Beitrag 1394173)

Seit wann muss man bei Count gruppieren?

SQL-Code:

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

[jobo]

Zitat:

Zitat von Neutral General (Beitrag 1394176)

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

Zitat von Neutral General (Beitrag 1394176)

Zitat:

Zitat von Delphi.Narium (Beitrag 1394173)

Seit wann muss man bei Count gruppieren?

SQL-Code:

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. :roll:
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?

SQL-Code:

select top 100 * from tabelle where bedingung

Kann maximal 100 Sätze liefern.

SQL-Code:

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

SQL-Code:

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:

SQL-Code:

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

[Neutral General]

Zitat:

Zitat von Delphi.Narium (Beitrag 1394182)

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

SQL-Code:

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! :thumb:

Zitat:

Zitat von p80286 (Beitrag 1394193)

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 8-)
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. :gruebel:

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1394289)

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

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.

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1394293)

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.

das ist doch schon mal was. Wenn die Abfrage wirklich so lange dauert, dann würde ich nicht nur hundert DS abrufen sondern deutlich mehr, bei einer lang laufenden Abfragen spielt dann ein Fetch von ein paar Sekunden dann auch keine Rolle mehr. Die Anzeige in der Oberfläche kannst Du dann anhand der lokalen Datenmenge einschränken und kannst dann deine Anzeige entsprechend gestalten, dass der Anwender noch mehr Datensätze abrufen kann..

[jobo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1394289)

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

Damit bekommst Du in jeder Rückbadezeile die Anzahl der Gesamtdatensätze als zusätzliche Spalte. Brauchst Du nicht.

Wenn ein count(*) schon zu lange dauert (mit einer entsprechend komplexen Bedingung), dann sind andere Sachen angesagt.

1. SQLite ist verbreitet, aber nicht unbedingt schnell
2. langsames SQL ist gern ein Indikator für unpassende Indizierung
3. aus 1 folgt, dass man vielleicht nach Alternativen schaut, unangenehm, aus 2 folgt: viel angenehmer, weil ggF. mit ein paar Handgriffen erledigt.
4. langsames SQL kann auch an einigen oder wenigen oder vielen "OR" Kriterien in der Bedingung liegen, in dem Fall ergibt es dann oft mehere "Fullscans", besonders schlecht bei großen Datenmengen, Singlepass und mitzählen ist dann schneller (was immer das auch erstmal für Dich bedeutet)
5. das alles ruft nach einem Blick auf den Ausführungsplan der Query
6. Leute, die eine "komplexe Bedingung" nicht zeigen (wollen), haben vielleicht was zu verbergen
7. ein Queryplan liefert immerhin brauchbare Indizien zu 1.-5., ohne all zu viel über Feldnamen usw. zu verraten
8. ein Queryplan kann man leichter "schminken", als eine komplexe Query
9. hier gibt Anleitung zu Query Plan: https://www.sqlite.org/eqp.html

Wenn Du Dich auf die ein oder andere Art mit Deiner komplexen Bedingung hier outest, kann Dir vielleicht geholfen werden.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1394299)

Damit bekommst Du in jeder Rückbadezeile

Dicke Finger?:duck:

Zitat:

Zitat von jobo (Beitrag 1394299)

6. Leute, die eine "komplexe Bedingung" nicht zeigen (wollen), haben vielleicht was zu verbergen

Hmm, da lehnst Du Dich etwas weit aus dem Fenster. Da kann es vielerlei Gründe geben, von "mit dem Kauderwelsch mach ich mich ja lächerlich" bis zum Verrat von Geschäftsgeheimnissen.

Da der schöne Mann nicht mehr ganz grün hinter den Ohren ist, hat er wohl gute Gründe das Original nicht zu Publizieren.

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1394304)

Dicke Finger?:duck:

Zitat:

Zitat von jobo (Beitrag 1394299)

6. Leute, die eine "komplexe Bedingung" nicht zeigen (wollen), haben vielleicht was zu verbergen

Hmm, da lehnst Du Dich etwas weit aus dem Fenster. Da kann es vielerlei Gründe geben, von "mit dem Kauderwelsch mach ich mich ja lächerlich" bis zum Verrat von Geschäftsgeheimnissen.

Da der schöne Mann nicht mehr ganz grün hinter den Ohren ist, hat er wohl gute Gründe das Original nicht zu Publizieren.

Ja, die Gicht ..., aber "Rückbaden" ist Althochdeutsch für "Ausbaden" und das müssen wir ja hier wohl alle mal ... ;)


Ja und ich lehn mich natürlich nicht aus dem Fenster, lediglich meine Gedanken scheinen so dick zu sein wie meine Finger.
Ich wollte nur eine Brücke bauen, auch wenn es niemand aufgefallen ist. Ob Scham oder Firmengeheimnis, es ist normal, dass gewisse Dinge nicht in einem Forum gepostet werden.
Das kann natürlich jeder halten wie er will, die Sache mit dem Explain Plan war gewisser maßen eine Alternative dazu.

Letztlich muss man in gewisser Weise "Klartext" reden. Wenn "komplexe Bedingung" ral für 20 x OR steht, kann man sich wahrscheinlich alle möglichen Tricks in die Haare schmieren. Explain wäre erst mal gut für etwas Klarheit.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1394318)

Ja und ich lehn mich natürlich nicht aus dem Fenster, lediglich meine Gedanken scheinen so dick zu sein wie meine Finger.

Nö soo dick nu auch wieder nicht. Ich kann mich allerdings noch gut erinnern, was für ein Aufwand/Eiertanz es war eine morsche Abfrage so zu formulieren, daß das wichtige rüber kam und trotzdem keine Rückschlüsse auf die verwendete Datenbank möglich war. Und um die Ohren gehauen zu bekommen, daß eine Tabelle suboptimal angelegt wurde ist auch nicht sooo erheiternd.

@Der schöne Günther
Wenn Du Millionen von Datensätzen erwarten kannst, ist es legitim sich auf die ersten hundert zu beschränken um etwas "Datengeschmack" zu bekommen. Sag mal um was es dir hier wirklich geht, bzw. warum Du die Einschränkung benötigst.
z.B. Die ersten Hundert holen um dem Benutzer Acion zu geben und dann den Rest hinterher, würde ich anders lösen.

Gruß
k-H

P.S.
Die Vorschläge von Jobo solltest Du Dir wirklich zu Herzen nehmen.

[Der schöne Günther]

Vielen Dank für alle Antworten. Auf drei Seiten habe ich es mit einer Frage schon lange nicht mehr geschafft :cyclops:

Ich kann meine Tabellenstruktur und Query gerne zur Diskussion stellen, die Frage "Wie optimiere ich diese spezielle Query?" ist dann aber sicher ein eigenes Thema wert.

Ich muss noch einmal klarstellen:

1. Ich habe kein Performance-Problem. Typischerweise wird die Treffermenge nach einem Zeitstempel eingeschränkt, auf diesem liegt ein Index. Typischerweise sind immer die neusten interessant. Es macht nur Sinn wenn diese GEORDNET nach Zeit aufeinander folgen.
2. Ich habe die Query nun auf tausend Treffer limitiert und bekomme auch in gigabyte-großen Datenbanken mein Ergebnis in wenigen Millisekunden
3. Das
   Delphi-Quellcode:

   Select COUNT(*)

   dauert, denke ich, so lange nicht weil die Bedingung zu komplex wäre, sondern weil wir hier über große Daten- und Treffermengen sprechen.
4. Ich bin mit der "+1"-Lösung zufrieden denn an sich entspringt kein Nutzen wenn ich weiß dass ich theoretisch 1,4 Millionen Treffer hätte haben können wenn der Arbeitsspeicher unendlich wäre.

Mein Anwendungsfall ist ein Datengrab in das kontinuierlich neue Messwerte gesteckt werden. Die Datenbank wird verwendet um entweder einen bestimmten Zeitbereich später genauer untersuchen zu können oder z.B. eine grafische Auswertung über einen längeren Zeitraum (mehrere Tage) zu malen. Dabei kommt es typischerweise vor dass man mehr über die jüngste Vergangenheit wissen will, trotzdem sollte man auch ein paar Monate zurück reisen können.

Für die ganz neugierigen, das war (ungefähr) die Query:

Code:

select
   tabelle1.pkey,
   [zeitstempel],
   [kurzerText],
   [kommazahl],
   [ganzzahl]
FROM
   tabelle1 JOIN tabelle2
ON
   (tabelle1.pkey = tabelle2.tabelle1_pkey)
WHERE
   (
      ((tabelle1.zeitstempel >= :timeMin) OR (CAST(:timeMin as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.zeitstempel <= :timeMax) OR (CAST(:timeMax as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.kurzerText = :textParameter) or ( CAST(:textParameter as SQL_VARCHAR) is NULL ))
   )
ORDER BY [zeitstempel] DESC LIMIT 1000;

[mkinzler]

Wirklich

Zitat:

SQL-Code:

ON
   (tabelle1.pkey = tabelle1_pkey)

?

-Die Prüfung auf NULL der Parameter besser vor dem Filter der Tabelle auf den Parameter (

SQL-Code:

(( CAST(:textParameter as SQL_VARCHAR) is NULL ) or (tabelle1.kurzerText = :textParameter))

)

-Möglicherweise hilft eine DERIVED TABLE

[Der schöne Günther]

Zitat:

Zitat von mkinzler (Beitrag 1394376)

Wirklich?

Delphi-Quellcode:

tabelle1_pkey

ist der FKEY von

Delphi-Quellcode:

tabelle2

auf

Delphi-Quellcode:

tabelle1

. Ja. Habe ich was dummes gemacht?

Zitat:

Zitat von mkinzler (Beitrag 1394376)

Die Prüfung auf NULL der Parameter besser vor dem Filter

Guter Tipp.

Derived Tables höre ich zum ersten mal, ich schaue mal was das ist...

[Jumpy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1394377)

Zitat:

Zitat von mkinzler (Beitrag 1394376)

Wirklich?

Delphi-Quellcode:

tabelle1_pkey

ist der FKEY von

Delphi-Quellcode:

tabelle2

auf

Delphi-Quellcode:

tabelle1

. Ja. Habe ich was dummes gemacht?

Ich hab auch erst gestutzt, weil ich "tabelle1.pkey = tabelle1.pkey" gelesen hatte und dann erst nachher gesehen habe, das da ja ein Unterstrich war. Mit "tabelle2.tabelle1_pkey" wäre es vllt. nicht so ins Auge gesprungen.

[Der schöne Günther]

Das stimmt, ich habe es abgeändert. Danke.

[jobo]

Wieso war ich der Meinung, dass es um SQLite geht?
Keine Ahnung.

Letztlich scheint sich ja alles in Wohlgefallen aufzulösen, auch wenn ich da zwischendrin Widersprüche sehe.

Zitat:

Zitat von Der schöne Günther

[*]Ich habe kein Performance-Problem.

Zitat:

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

"Datengräber" sind ja dann vielleicht auch wie der Name andeutet nicht unbedingt etwas für adhoc Zugriff. Bewegung im Grab ist langsam. Will man trotzdem "at your fingertips" haben, geht es Richtung Datawarehouse, Starschema usw., die Daten werden nicht nur begraben, sondern man notiert sich einmalig wann, wieviel, wovon, wo und bietet das zum Browsen an.

Jenseits von SQLite gibt es natürlich in echten RDBMS und ohne gleich ein Datawarehouse zu eröffnen auch Technologien, die eine bessere Skalierung der Zugriffszeiten ermöglichen, "Partitionierung" mal als ein Stichwort.

[p80286]

Ich habe mit der Abfrage ein leichtes Problem

Zitat:

Zitat von Der schöne Günther (Beitrag 1394375)

SQL-Code:

select
   tabelle1.pkey,
   [zeitstempel],
   [kurzerText],
   [kommazahl],
   [ganzzahl]
FROM
   tabelle1 JOIN tabelle2
ON
   (tabelle1.pkey = tabelle2.tabelle1_pkey)
WHERE
   (
      ((tabelle1.zeitstempel >= :timeMin) OR (CAST(:timeMin as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.zeitstempel <= :timeMax) OR (CAST(:timeMax as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.kurzerText = :textParameter) or ( CAST(:textParameter as SQL_VARCHAR) is NULL ))
   )
ORDER BY [zeitstempel] DESC LIMIT 1000;

Das liest sich wie, wenn keine Werte (min,max,text) übergeben werden, dann liefere alles!
Wahrscheinlich gibt es in der GUI eine Logik, die das verhindert aber Unbehagen bereitet mir das trotzdem.
Ad hoc würde ich da drei Abfragen verwenden.

Gruß
K-H

[jobo]

Naja, halt die letzten 1000?

[Der schöne Günther]

Eben: Wenn zeitlich nicht eingegrenzt, dann einfach die 1000 neusten. Dank des Index auf dem Zeitstempel-Feld ist das Ergebnis hierzu in wenigen Millisekunden da. Suche ich ohne zeitliche Einschränkung nach "kurzerText" und es gibt nur ein paar Handvoll Treffer von vor ein paar Jahren dauert es ein paar hundert Millisekunden, aber auch das finde ich völlig akzeptabel. Einen Index auf das Textfeld habe ich nicht.