Wir müssen (bzw. wollen) bis zu 5000 Aufträge im Speicher halten, weil die Disponenten beim Anruf eines Kunden schnell die richtigen Aufträge finden müssen. Eine
Query dauert dann leider doch etwas, weil auch Großkunden mit mehreren Hundert Aufträgen dabei sind. Und pro Auftrag sind es 300-400 Details, die mit geladen werden, also schon einiges an Daten.
Das Finden und Filtern der Aufträge sowie das Einpflegen der Änderungen sollte ja möglichst bereits in der Datenbank geschehen. Durch das Bearbeiten im Client gibt es ja einige Probleme:
- Zumindest die Übertragung großer Datenmengen.
- Redundanz (Clientdaten <-> Serverdaten), dadurch vielleicht unterschiedliche Version bei verschiedenen Nutzern.
- Keine Transaktionen.
- Geänderte Daten sind nicht crashsave in der Datenbank, sondern liegen beim Client im Speicher.
Andererseits könnte man das Ganze als Caching
* bezeichnen, was ja nötig sein kann, wenn der Rechner schlecht an das Datenbanksystem angebunden ist.
Aber bei einer
lokalen Datenbank sollte es in den meisten Fällen Schwachsinn sein.
* Obwohl ich 5000+ Datensatze irgendwie schon ziemlich extrem finde.
Achtung:
Das ist die Sicht, die ich aktuell nach dem Genuss einer (einzigen) Datenbankvorlesung habe.
Ich will nicht behaupten, dass du bei deinem konkreten Anwendungsfall etwas falsch machst.