"Single-User" -> "Multi-User" + SQLite

[Ghostwalker]

Ich persönlich würde die Kommunikation und das DB Handling in ein eigenes Serverprogramm ohne GUI (Dienst/Daemon) auslagern. Das Serverprogramm nimmt die Daten der Clients entgegen, packt diese in eine Que. Ein eigener Thread des Serverprogramm arbeitet die Que ab und trägt diese in die DB ein.

Vorteile:

- Keine Synchronisatzion mit einer GUI
- Keine Blockade der Clients
- Wenns zuviel wird, kann man das ganze auf einen eigenen Rechner auslagern.

[Mavarik]

Zitat von Ghostwalker:

Ich persönlich würde die Kommunikation und das DB Handling in ein eigenes Serverprogramm ohne GUI (Dienst/Daemon) auslagern. Das Serverprogramm nimmt die Daten der Clients entgegen, packt diese in eine Que. Ein eigener Thread des Serverprogramm arbeitet die Que ab und trägt diese in die DB ein.

Sicherlich ein guter Vorschlag!

Aber muss man nicht in jeder App, egal ob Windows, iOS oder Android, die Datenbankzugriffe kapseln?

Ich hatte noch nie ne App bei der ich nicht Daten in einem Thread weg schreibe oder Daten lese, während die UI auch Daten anfordert oder schreiben möchte?

Wenn ich also immer asynchron mit CRUD arbeite habe ich "keine" Probleme egal wie die Anwendung aus sieht.

Es gibt natürlich Situationen, wo die UI auf ein Ergebnis der Datenbank warten muss. Aber wovon sprechen wir hier? 250ms? 1s? 3s?

Wenn ich auf einen Button klicke, erwarte ich eine sofortige Reaktion. IMMER, damit sich die Anwendung flüssig "anfühlt". Wenn also ein Zugriff länger dauert, muss ich sowieso eine Art von Stundenglas/Wait-Animation anzeigen.
Naja und die kann sich auch nur flüssig drehen, wenn mein DB-Zugriff in einem eigenen Thread ist...

Also sind ALLE Datenbankzugriff immer in einem Thread. Hier also einen Queue einzufügen, die dann auch gerne Datenbankanfragen von mehrerer Quellen abhandeln kann ist kein Hexenwerk. Wenn ich dann noch anfragen der lokalen App bevorzuge, läuft alles schnell und sauber.

Wäre es nicht schön, wenn es für Firemonkey ein Framework gäbe, dass so etwas kann?

Mavarik

[Ghostwalker]

Naja, einfach ist es schon.

Die Frage nach der Priorisierung der Zugriffe, ist eine Frage, wie aktuell die Daten für die Clients sein müssen.

Beispiel:

Client A braucht unbedingt die Daten von Client B, die dieser gerade in die Que zum eintragen geschickt hat.

Dann sollte der Schreibzugriff natürlich oberste Prio haben.

Eine andere Situation, die man noch berücksichtigen könnte, wäre, das die Clients auch "Offline" arbeiten können sollen. Dann wärs sinnvoll die Clients mit einer eigenen "lokalen" DB arbeiten zu lassen, die dann entsprechend mit der zentralen Version synchronisiert werden.

[p80286]

Angeblich sollen DBMS das von Hause aus können, aber ich kann mich auch irren.

Gruß
K-H