TUniQuery liefert falschen RecordCount

[hstreicher]

diese ganze Count's sind eigentlich nur Kaffeesatzlesen , denn die Datenbanken sind Multiuser
und waehrend sich der Count-Thread abquaelt können hinten 1000 Records gelöscht worden sein ,
oder vorne 1000 dazukommen
dazu reicht ein einfaches Commit;

mfg Hannes

[Perlsau]

Zitat von hstreicher:

diese ganze Count's sind eigentlich nur Kaffeesatzlesen , denn die Datenbanken sind Multiuser
und waehrend sich der Count-Thread abquaelt können hinten 1000 Records gelöscht worden sein ,
oder vorne 1000 dazukommen
dazu reicht ein einfaches Commit;

Auch wenn du dir in deiner Polemik gefällst, paßt da so einiges nicht, denn:

1. Nicht jede Datenbank wird ständig von mehreren Usern in Anspruch genommen, viele sogar immer nur von einem User. Was genau für die DB des TE zutrifft, mußt du ihn selbst fragen, was für das Problem des TE aber vollkommen irrelevant ist.

2. Ein Count, egal woher, zeigt immer nur die aktuelle Anzahl der vorhandenen Records, auch wenn dieser Wert sich bei manchen Datenbanken sehr schnell ändern kann. Deswegen ist das noch lange keine Kaffeesatzleserei, was ja bedeuten würde, der Wert würde erraten oder basiere auf irgendwelchen esoterischen Tricks.

3. Deiner Ansicht nach dürfte man wohl niemals danach fragen, wie viele Datensätze in einer Tabelle gerade gespeichert sind. Ist irgendwie so wie mit dem Putzen: Wenn man sich mit der Ausrede, daß die Treppe ja sowieso wieder dreckig würde, ständig darum drückt, sie zu wischen, geht man eines Tages auf einer zentimeterdicken Dreckschicht. Oder gibt es deiner Ansicht nach keinen vernünftigen Grund, die Anzahl der vorhandenen Datensätze ermitteln zu wollen? Wenn doch, wäre es interessant zu lesen, wie du diesen Wert ermitteln würdest.

[nahpets]

Zitat von hstreicher:

diese ganze Count's sind eigentlich nur Kaffeesatzlesen , denn die Datenbanken sind Multiuser
und waehrend sich der Count-Thread abquaelt können hinten 1000 Records gelöscht worden sein ,
oder vorne 1000 dazukommen
dazu reicht ein einfaches Commit;

mfg Hannes

na, wenn dem so ist, dann ist auch ein Last Kaffeesatzlesen, denn in der Zeit, in der der Client die Daten von der Datenbank empfängt, können andere Nutzer 1000e von Datensätzen hinzufügen, ändern oder entfernen.
Man sieht in allen Fällen nur das, was in der eigenen Session ist, bis zum nächsten eigenen Commit oder Rollback. Erst danach kann man den dann aktuellen Stand der DB abfragen, der zu diesem Zeitpunkt per Commit oder Rollback aller Nutzer festgeschrieben ist. Man erhält immer nur eine Momentaufnahme, da zeitgleich andere Änderungen an den Daten vornehmen können.
Unter diesen Bedingungen ist also letztlich jede Abfrage nur eine Art "Kaffeesatzlesen". Und das sollte jedem, der keinen Exklusivzugriff auf eine Datenbank hat, klar sein.

Ob in RecordCount letztlich ein "korrekter" Wert steht ist datenbankabhängig. Manche Datenbank liefert diesen Wert sofort, andere nicht. Häufig enthält RecordCount die Anzahl der Sätze, die bisher per Fetch an den Client geliefert wurden. Die Datenbank weiß zu diesem Zeitpunkt nicht zwingend schon, wie groß die Satzzahl der Abfrage sein wird, da sie immer nur soviele Datensätze der Ergebnismenge ermittelt, wie per Fetch angefordert wurden. Zum Zeitpunkt der Lieferung der ersten Daten der Ergebnismenge muss eine Abfrage noch lange nicht über die gesamten Ergebnismenge verfügen, also vollständig ausgeführt sein. D. h.: Der Wert für RecordCount ist der Datenbank auch nicht unbedingt jederzeit bekannt, aber das ist datenbankabhängig. Auch das Verhalten der einzelnen Datenbankkomponenten ist hier unterschiedlich.

[jobo]

Ein Select count(*) sollte in jedem Fall(!) schneller sein, als das vollständige Laden (Last) der Daten auf den Client. Selbst wenn es eine lokale DB ist, muss an dieser Stelle die Datenmenge von der DB-Datei mindestens in den Anwendungsspeicher übertragen werden.
Eine halbwegs schlaue Implementierung bzw. Optimierung einer Count(*) Anfrage wird außerdem nicht die Datenmenge aufbauen (wozu, wollte keiner wissen), sondern nur die join - und where Kriterien prüfen und zählen.
Und das sollte jedes am Markt etabliertes RDBMS sehr gut können. Genauer gesagt, sollte jeder Server selbst am besten wissen, wie er die exakte Ergebnismenge so schnell wie möglich bestimmt. Das vollständige Laden und Durchzählen am Client ist dagegen brute force. (Wenn ich weiß, dass ich auf jeden Fall alle diese Daten brauche, ist es natürlich egal bzw. sinnlos, sie separat per Count zu zählen)
Sinnlos ist eine eigene Verwaltung von Datenmengen. Dieses Rad wurde schon erfunden und zwar von den Anbietern der RDBMS, spätestens beim ersten Join nützt die Eigenimplementierung wohl eh nichts.
Ich beziehe mich damit auf echte RDBMS, keine BDE, ISAM usw Systeme.

P.S.: Ich kann auch in einem SingleUser System ohne Probleme verschiedene Counts zustande bringen, sobald ich mit getrennten Connections/Transaktionen arbeite, threaded, .. arbeite. Beispielsweise bei einem Datenimport im Hintergrund, der dummerweise vielleicht sogar noch mit Teilcommits. implementiert ist.

[p80286]

Zitat von hstreicher:

diese ganze Count's sind eigentlich nur Kaffeesatzlesen

Wenn man glaubt, daß da verläßliche Daten für die nächsten ...Minuten/Stunden/Tage herum kommen. Wenn eine Query 1234 Datensätze liefert, dann ist das eine Momentaufnahme, ein einfaches distinct kann da schon die zurück gelieferte Datenmenge auf ein viertel oder weniger schrumpfen lassen, und wenn das bei einem "select * from tabelle" der Fall ist, sollte man sein DB-Design einmal überprüfen.

Zumindestens unter Oracle ist ist ein count(irgendwas) immer wesentlich schneller als ein .last. und wenn's unbedingt nötig ist kann man ja beim Auslesen mitzählen.

Gruß
K-H