Denkanstoß MemTable/Cachetable FireDac

[Delphi.Narium]

Die ID für den Zeitraum 01.01.2020 - 31.12.2020 ist doch wohl schon immer gleich?

Wie oft musst Du denn auf diese Daten zugreifen: andauernd, permanent (also quasi sekündlich oder öfter) oder eher sporadisch (also eher: Immer dann, wenn ein User einen Geschäftvorfall bearbeitet, was halt eher mal ein paar Minuten länger dauert)?

Im zweiten Fall einfach bei Bedarf das Select absetzen und nachschauen. Dafür lohnt es sich nicht, die Daten permanent vorzuhalten und sie sind dann garantiert immer aktuell.

Wenn Du

Zitat:

Wenn ich die Abfrage benutze, zuerst ein Reopen (könnte ja sein, dass sich was geändert hat).
Dann per Locate drauf zugreifen.

es so machst, wofür der Aufwand einer MemoryTable. Du hast die Daten doch dann sowieso schon in 'ner Query.

Statt Locate gibt es auch noch Filter.

Datenmenge?

Nicht besonders groß (ein paar hundert Sätze dürfen es schon sein)?

Delphi-Quellcode:

  Query.Filtered := false;
  Query.Filter   := Format('DatumVon = %s and DatumBis = %s',[QuotedStr(Var_DatumVon),QuotedStr(Var_DatumBis)]);
  Query.Filtered := true;

// oder

  Query.Filtered := false;
  Query.Filter   := Format('DatumVon = %d and DatumBis = %d',[2020,2021]);
  Query.Filtered := true;

Wenn Du für jeden Zeitraum genau einen Datensatz hast, stehst Du sofort dadrauf und brauchst nicht weitersuchen. Sind für einen Zeitraum mehrere Datensätze möglich, so musst Du die "Restmenge" durchgehen oder halt den Filter entsprechend erweitern, um als Ergebnis nur einen Datensatz zu erhalten. Ist die Filtermenge leer, dann gibt es das Gesuchte halt nicht.

Im Filter kann man (fast) alles nutzen, was man im Where des SQLs auch "anstellen" kann, solange es um Bedingungen wie = >= <= <> and or geht. (Weitergehendes, wenn nötig, probieren.)

Beim Filter selbst muss Du mal ausprobieren, welcher Datentyp von Seiten Delphis und der DB am besten für Deinen konkreten Fall geeignet ist. Prinzipiell sollte es aber so gehen.

Filter und Filtered gibt es ab TDBDataset. Alles, was davon abgeleitet ist, sollte diese Funktionalität aufweisen.

[Eppos]

Vielen Dank für die ausführliche Beschreibung. Das mit dem Filter werde ich ausprobieren.

Der Zugriff erfolgt während einer Sekunde ca. 10 mal. Aber nur ein paar mal am Tag. Dies für eine Dauer von 5 Minuten. (Prüfprogramm)
Von der memoryTable bin ich weggegangen und hin zu einem DataSet welchen ich vorhalte.

Die ID für einen Zeitraum ist gleich jedoch kann sich innerhalb dieses Zeitraum Tages/Monatsbeschränkungen ergeben die es nicht erlauben den Datensatz zu verarbeiten.

[haentschman]

Zitat:

Das mit dem Filter werde ich ausprobieren.

...du weißt, daß alle Daten geladen werden und dann die Filterung am Client passiert?
Beispiel:
In der Datenbank sind 10000 Datensätze. Du willst nur die 10 Datensätze haben vom/bis. Die kriegst du dann auch angezeigt. Trotzden wurden alle 10000 geladen.
Besser eine Query mit den Kriterien...und es kommen nur 10 Datensätze.

[Delphi.Narium]

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.

[Eppos]

Also grundsätzlich wird bisher immer ein SQL mit der entsprechenden Where-Bedingungn abgesetzt. Dies funktioniert auch schnell, aber der Mitarbeiter muss warten, also er startet das Prüfprogramm.
Und die ständige Abfrage dauert immer ca. 30 ms. Dies ist nicht die einzige Tabelle die Daten beinhaltet, die zur Prüfung notwendig sind.

In der besagten Tabelle sind nur 10-50 Datensätze enthalten, diese in den Speichern zu nehmen und über den Filter einzugrenzen sehe ich als Peformanceverbesserung an.
In einer weiteren Tabelle benfalls nur 10-20.

[Delphi.Narium]

Also jetzt haben wir mal eine Mengenangabe.

Bei so kleinen Mengen ist ein Filter sinnvoll.

Und wenn Du davon ein paar Tabellen hast, sehe ich keinen Grund, warum Du das nicht so machen solltest.

[Eppos]

Perfekt, dickes Danke schön!