Wenn ein Prüfprogramm, dann muss kein User "endloslange" warten und kann nicht meckern.
Wäre es denn schlimm, wenn aus den 10 mal pro Sekunde ein 9,5 mal pro Sekunde wird und aus den ca. 5 Minuten ein ca. 5 Minuten und 3 Sekunden?
Probier' doch einfach erstmal aus, ob es nicht sinnvoller ist, die Daten konkret bei Bedarf per
SQL abzufragen. Wenn bei FireBird eine Abfrage (mit sehr ähnlicher Wherebedingung) sehr oft hintereinander genutzt wird, ist das "Zeugs" eh noch im Cache, im Speicher und (nach meiner Erfahrung) affig schnell.
Es wäre also erstmal zu prüfen, ob das, was Du vorhast, aus Performanzgründen überhaupt erforderlich ist. Wenn Du Pech hast, dauert die MemoryTable und der Einleseaufwand, oder das Setzen und Nutzen der Filter insgesamt länger, als die (vermuteten) 3000 Abfragen (10 * pro Sekunde * 60 Sekunden pro Minute * 5 Minuten).
@haentschman
Du weißt, dass er vorhatte alle Daten in den Arbeitsspeicher (eine MemoryTable zu laden). Und jetzt sag mir nicht, dass die dann nicht im Arbeitsspeicher liegen. Wir tauschen also hier gerade Arbeitsspeicher gegen Arbeitsspeicher?
Hast Du dafür jetzt eine sinnvolle Begründung, warum die Daten in 'ner Memorytable, 'nem TDirectory im Arbeitsspeicher sinnvoll sein könnten, in 'ner
Query aber nicht?
Und ich schrieb: Sinnvoll bei ein paar 100 Sätzen. Also: Wenig. Bei 10000den oder gar Millionen ist es natürlich absoluter Humbug mit Filtern zu arbeiten. Dann ist aber auch ein Locate völlig daneben und 'ne Memorytable und ein TDirectory ebenso.
Ein Problem bei vielen Programmieren ist leider, dass sie die Leistungsfähigkeit von modernen Datenbanksystemen gnadenlos unterschätzen und deshalb mit viel Aufwand im Programm das nachbauen, was sie von der Datenbank selbst mit 'nem einfachen select mal eben performant geliefert bekommt.
Zitat
Baum-Darstellung
