Software-Datenmodell Redesign - Möglichkeiten

[SusiT]

Korrekt, die Datenänderungen kommen vom Server. Dort gehen über andere Wege Daten ein, werden aufbereitet und in einer Datenbank gespeichert. Via einem internen Eventing-System werden
dann die geöffneten Clients mit den Datensätzen "versorgt". Somit ist ein "abholen" der Daten durch den Client nicht die beste Lösung.

Die Anzahl der geöffneten Clients variiert zwischen 1-20, mehr werden es nicht.
Bei der Größe der Datensätze gibt es Unterschiede, es können von 20 Datensätze/Stunde bis 5000 Datensätze/Stunde Daten eingehen. Das hängt von mehreren unterschiedlichen Faktoren ab.
Ein Datensatz hat laut Tabellendefinition ca. 4 Kilobyte. Natürlich gibt es noch weitere Tabellen die ebenfalls Änderungen erhalten und über das Eventing-System aktualisiert/ergänzt werden.

Wichtig dabei ist noch zu erwähnen, das jeder Client nicht unbedingt die selben Datensätze erhält, das ist abhängig von den Sichtrechten des jeweils angemeldeten Benutzers.
Die Selektierung der Events pro Benutzer/Client erfolgt aber bereits über das Event-System innerhalb der Datenbank, sodass die Insert/Update/Delete Events bereits aufbereitet in einer entsprechenden Tabelle vorliegen. Dieser Eintrag beinhaltet dann die Information welcher angemeldete Benutzer, welchen Datensatz aus welcher Tabelle "nachgeschoben" bekommt und ob es sich um ein Insert/Update/Delete handelt.


Es können sowohl Boardmittel als auch kommerzielle Produkte von Drittanbietern in Frage kommen. Boardmittel werden natürlich bevorzugt, sollte eine Drittanbieter-Lösung aber den Entwicklungsaufwand beschleunigen so ist diese auch von Interesse.


Generell ist eine Modernisierung angedacht da sich bei höherem Datendurchsatz (den gab es in unserer Anwendung früher nicht, aber die Anforderungen änderten sich über die Jahre)
die Anwendung in der Handhabung etwas verschlechtert, zum Teil verzögert sich das öffnen von weiteren Formularen die auf bestimmte ClientDataSets zugreifen da dieses gerade durch Update-Vorgänge geblockt sind. Da die Client PCs zum Teil auch etwas veraltet sein können, ist auch das Datenmanagement hinsichtlich des Arbeitsspeichers nicht zu vernachlässigen.

Im Optimalfall wäre da eine getrennte, Threadsafe Möglichkeit, sodass die Usability nicht unter der Datenlast leidet.

[Papaschlumpf73]

Dann würde ich im ersten Schritt prüfen, ob der Flaschenhals tatsächlich bei den Clients oder am Server ist. Wenn es nur die Clients sind, würde ich das ganze System nicht über den Haufen werfen, sondern nur die Verarbeitung der Datensatzänderungen auf den Clients optimieren. Never change a running system.

[SusiT]

Erstmal danke für eure schnellen Reaktionen und Anregungen.

Der Server sendet soweit zuverlässig und schnell, dort sehe ich soweit erstmal keine Probleme.

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?
Oder finden Zugriff innerhalb einer Multi-Thread-Anwendung auf DataSets generell nur via CriticalSections o.Ä. statt?

[jaenicke]

Zitat von SusiT:

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?
Oder finden Zugriff innerhalb einer Multi-Thread-Anwendung auf DataSets generell nur via CriticalSections o.Ä. statt?

Soweit ich weiß, gibt es das nicht.

Das hat aber auch den Hintergrund, dass du Locks bei einer eigenen Implementierung optimieren kannst, während eine allgemeine threadsichere Implementierung alles absichern müsste.

FireDAC ist z.B. bei reinen Lesezugriffen auf geklonte Datasets threadsafe.

Eine Idee zur Optimierung:
Halte einfach für jeden Client zwei DataSets vor. Eins ist das, das bei einer Anfrage geliefert wird, das andere bekommt ein Update. Nach dem Update tauschst du threadsicher die beiden DataSets aus.

Das hat den Vorteil, dass eine Datenanfrage immer schnell beantwortet wird, dafür eine im Moment der Anfrage eingespielte Datenänderung erst bei der nächsten Lieferung enthalten ist.

Ich bin gerade im Urlaub und schreibe am Handy. Insofern kann ich aktuell schlecht recherchieren.

[Papaschlumpf73]

Zitat von SusiT:

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?

Das kann ich mir kaum vorstellen. Ich würde die Datenaktualisierung auch immer nur seriell vornehmen. Wenn z.B. ein Datensatz geändert und kurz danach gelöscht wird (auf dem Server), und der Client verarbeitet die beiden Änderungen nicht seriell, könnte der Datensatz im Client zuerst gelöscht und dann... nicht mehr gefunden werden.

[Uwe Raabe]

Ich könnte mir vorstellen, dass ein Abrufen der Daten mit einer TFDQuery unter den FireDAC-Regeln für Multi-Threading mit anschließend synchronisierter Übergabe an ein TFDMemTable in den Hauptthread durch simples Zuweisen des Data Properties ein brauchbarer Ansatz wäre.

[SusiT]

@PapaSchlumpf73:

Da hast du vollkommen recht, dieses Szenario habe ich so nicht bedacht.

@jaenicke:

Die Idee für die Optimierung klingt einleuchtend. Im Grunde halte ich dann ein CDS in einem separaten Event-Thread welcher die Updates erhält und in sein CDS einfügt.
Nach dem erfolgreichen Einfügen könnte ich den kompletten Inhalt des CDS dann in das CDS im MainThread kopieren.

Wäre es auch möglich via CloneCursor die Anzeige im MainThread auf die im Event-Thread zu referenzieren? Im Grunde "lese" ich die Daten ja ausschließlich im MainThread um sie dort dem Benutzer zu präsentieren. Oder geht das mit herkömmlichen ClientDataSets nicht und ich müsste auf die FireDac Äquivalente umsteigen?


@Uwe Raabe:

Das ist so leider nicht möglich da die Clients keine direkte Verbindung zur Datenbank haben.