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.
Zitat
Baum-Darstellung
