Wenn ich den RecordCount einer Tabelle zwingend korrekt benötige mache ich einfach ein:
Code:
select count(*) as Anzahl from Tabelle
Und das wäre dann aus welchem Grund schneller als ein
Query.Last?
Das in einer extra Tabelle zu verwalten dürfte schnell recht aufwändig werden, da jedes Insert oder Delete dann diesen Verwaltungsschritt auslösen müsste und dann letztlich auch nur das Ergebnis des obigen
SQL je Tabelle in der Verwaltungstabelle speichern müsste.
Bei einer Tabelle mit zahlreichen Spalten (große VarChars und etliche Blobs) und Millionen von Datensätzen kann das aber schon Geschwindigkeitsvorteile bringen, wenn es um das Ermitteln des RecordCount geht, denn es würde das Durchzählen ersparen. Was spräche denn dagegen, mittels entsprechender StoredProcedures, die von den Triggern AfterInsert und AfterDelete ausgelöst werden, diesen einen Eintrag vorzunehmen? Man könnte auf diese Weise sogar den RecordCount aller Tabellen auf dem aktuellen Stand halten, wenn es notwendig wäre. Ich bin mir sicher, daß bei sehr großen Datenbanken (z.B. denen der NSA oder auch denen der EU-Vorratsdatenspeicherung) solche Mechanismen angewendet werden.