[FB 2.1] Schnelle Alternative zu Count(*) ?

[brechi]

Aber die Update operation für die Spalte mit der Anzahl sollte ebenfalls rückgägnig gemacht werden (da Transaktion). d.h. bei Insert (datensatz) -> Trigger -> Update (inc) wird das inkerementeiren ebenfalls rückgängig gemacht. Jedenfalls die Theorie.

[exilant]

Nach nunmehr 40 Einträgen zu diesem Thread möchte ich mit Verlaub mal die
Frage stellen: Kann es sein, das hier ein Problem mit dem Datenbank/Anwendungsdesign vorliegt?
Ich habe in meiner nun auch schon recht langen Praxis noch nie eine absolute Datensatzanzahl (was immer das ist)
einer Tabelle (und schon garnicht von einer derart großen) benötigt. Und wenn die Anzahl ja doch benötigt wird: Wieso wird dieses count() Ergebnis so häufig benötigt dass es ein Performanceproblem gibt?
Ich bin einfach nur neugierig.

[sirius]

Kann dieses FB keine Stored Procedures. Da kann man doch mitzählen.

[mkinzler]

Zitat:

Kann dieses FB keine Stored Procedures. Da kann man doch mitzählen.

Doch, wird aber auch nicht (viel) schneller sein

[alzaimar]

Zitat:

Zitat von exilant

Kann es sein, das hier ein Problem mit dem Datenbank/Anwendungsdesign vorliegt?...Wieso wird dieses count() Ergebnis so häufig benötigt dass es ein Performanceproblem gibt? Ich bin einfach nur neugierig.

Einfacher DB-Puffer. Anzahl der gepufferten Datensätze soll laufend angezeigt werden. Wenn die Anwendung läuft, zähle ich intern mit (Singleuser-DB), also kein Performanceproblem. Wäre ja auch bescheuert, 1x pro Sekunde alle Datensätze zu zählen. Beim Programmstart muss ich aber wissen, wie viele Datensätze jetzt gerade in der DB rumliegen. Bei 1Mio gepufferten Daten dauert mir dieses eine "COUNT(*)" zu lang. Die Anwendung darf nunmal nicht 30-40 Sekunden warten, bis sie gestartet ist. Oder?
[quote]Ich habe in meiner nun auch schon recht langen Praxis noch nie eine absolute Datensatzanzahl (was immer das ist){/quote] Nun ja, bei Statistiken ist das schon interessant... Die 'absolute Datensatzanzahl' ist übrigens die absolute Anzahl der Datensätze. Was sonst. :stupid: Also ein 'COUNT(*) FROM TABELLE'. So schwer ist das doch nicht. :mrgreen:

[omata]

Zitat:

Zitat von alzaimar

Die Anwendung darf nunmal nicht 30-40 Sekunden warten, bis sie gestartet ist. Oder?

Nur mal so eine Idee...

Vielleicht die Ermittlung in einen Thread auslagern, dann kann die Anwendung starten, man kann arbeiten und wenn die Zahl ermittelt wurde, werden die gewünschten Statistiken angezeigt.

[TBx]

Was hast Du da für ne Tabellenstruktur? Und was für ein Rechner wird genutzt?
Ich habe hier mal eine Tabelle mit 1,1 Mio Datensätzen mit Zufallswerten angelegt. Da krieg ich ein count unter 3 Sekunden hin.

[alzaimar]

Hi Tbx.
Eine Tabelle: ID (Int), Data (BLOB, Text), inDate (TimeStamp), Source (Varchar(80))

Rechner ist ein IBM Schlapptop R61 oder irgend so eine Gurke (Firmenlaptop).

[TBx]

Ist das PK-Feld das erste in der Tabellendefinition? Zeig ggf. mal einen DDL-Extract der Tabelle.

Gruß
Thomas

[hoika]

Hallo,

Zitat:

Die Anwendung darf nunmal nicht 30-40 Sekunden warten, bis sie gestartet ist. Oder?

Spash-Screen.
Haben Sie bitte einen Moment Geduld. tüt tüt ...;)


Ne, im Ernst.
30-40 Sekunden dauert das count(*) ???
Hast du das mal standalone getestet (ibexpert)


Noch zur Berechtigung des count(*).
Wie bekommt man z.B. sonst raus, ob eine Tabelle Daten enthält ?
(OK, bei FB gibt es exists)


Heiko