AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi "Single-User" -> "Multi-User" + SQLite

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

Ein Thema von wjjw · begonnen am 21. Feb 2019 · letzter Beitrag vom 24. Feb 2019
Antwort Antwort
Seite 1 von 2  1 2   
Benutzerbild von wjjw
wjjw

Registriert seit: 3. Aug 2017
Ort: Wiener Neustadt
29 Beiträge
 
Delphi 10.3 Rio
 
#1

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

  Alt 21. Feb 2019, 10:06
Hallo!

Ich habe ein Programm das bis dato im "Single-User" Modus läuft.
Nun soll das Programm auf Multi-User laufen - was bei mir folgendes heisst:
A) Im Hauptprogramm "X" arbeitet ein Benutzer (Windows, Android, iOS)
B) Die Companion-App "Y" läuft auf mehreren mobilen Gräten (Android, iOS, Windows)
C) Die mobilen Apps "Y" schicken Daten an das Hauptprogramm "X"
D) Alle Programme kommunizieren im lokalen Netzwerk (kein Internet oder Cloud)

Nun möchte ich nicht das Hauptprogramm "zu viel" durch die mobilen Apps blockieren und umgekehrt -> Threads.
Problem ist das ich als Datenbank SQLite einsetze (da es auf jeder Platform verfügbar).
Die Datenbankoperationen hab ich schon gekappselt.
Es gibt einige Techniken das umzusetzen, jedoch welche passt bei dem Fall am Besten? TWorker, Critical Sections, ...
Die Datenpakete, die ich von den mobilen Apps bekomme, sind nicht groß - im Prinzip einzelne Datensätze bis zu 50 an der Zahl.

Vielleicht hat ja jemand eine Idee oder ein ähnliches Projekt umgesetzt.
Werner Weiß
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.259 Beiträge
 
Delphi 10.3 Rio
 
#2

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

  Alt 21. Feb 2019, 10:15
Wenn es ohnehin alles gekapselt ist und die Kommunikation über das Windowsprogramm läuft, dann steck noch etwas Hirnschmalz dort rein. Daten Lesen sollte kein Problem darstellen. Du mußt Dich um Transaktionen kümmern, die zu Änderungen führen. Da könnte initial eine simple Datensatzsperre ausreichen. Wer also Daten ändern will, muß dies irgendwie in der Applikation signalisieren (zB. durch Drücken eines Ändern-Buttons). Dann wird (Ich glaube bei SQLite nötig) die komplette DB für andere als gesperrt markiert, und die müssen gegebenenfalls warten, bis sie ändern dürfen. Natürlich mußt du dir über einen Timeout Gedanken machen, und so weiter.

Sherlock
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.234 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#3

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

  Alt 21. Feb 2019, 10:33
Ich würde die Fähigkeit eines DBMS nutzen anstatt diese mir selber zusammenzubasteln.
GGf. zusätzlich den Datenzugriff per REST kapseln, für den Zugriff von mobilen Geräten ist das sowieso sinnvoll.
Markus Kinzler

Geändert von mkinzler (21. Feb 2019 um 10:39 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.257 Beiträge
 
Delphi 7 Personal
 
#4

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

  Alt 21. Feb 2019, 22:07
Spätesens wenn "X" nicht läuft, warum auch immer, fährt das Konzept vor die Wand.

Und SQLite auf "Multiuser" aufzublasen mag als Studie interessant sein, für den praktischen Einsatz gibt es bessere DBMS.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von wjjw
wjjw

Registriert seit: 3. Aug 2017
Ort: Wiener Neustadt
29 Beiträge
 
Delphi 10.3 Rio
 
#5

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

  Alt 22. Feb 2019, 13:02
Spätesens wenn "X" nicht läuft, warum auch immer, fährt das Konzept vor die Wand.
Ja das ist richtig, wenn ein Server nicht läuft, können die Clients nicht darauf zugreifen. Ist bei jedem C/S Konzept so.

Zitat:
Und SQLite auf "Multiuser" aufzublasen mag als Studie interessant sein, für den praktischen Einsatz gibt es bessere DBMS.
Welche??
Werner Weiß
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.454 Beiträge
 
Delphi 2010 Enterprise
 
#6

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

  Alt 22. Feb 2019, 13:15
zu "Anwendung X läuft nicht"
Natürlich ist das so auch bei einem Server, ich vermute es ging hier darum, dass eine Anwendung eben kein Server sein sollte. Ein Server läuft ohne nennenswerte Userinteraktion vor sich hin, bei einer Anwendung (auf einem Deskopt) ist das wohl anders. Es geht einfach um Risiko Minimierung.

Welche DB
Wenn Du hier die DB Threads durchgehst, wirst Du immer wieder die gleichen Kandidaten finden

kostenlos, nicht umsonst:
firebird
postgres
mysql/maria

kommerziell:
interbase
mssql
oracle


Am nächsten an sqlite sehe ich da firebird (embedded). Neben der Einhaltung gewisser Standards (ANSI SQL XY) bieten alle diese Systeme die ein oder andere Spezialität.
Wie gesagt, es gibt hier viele Threads zu diesen Themen, da kannst Du ja mal stöbern.

Oder gezielt nachfragen, wenn Du Deine Anforderungen klar hast.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
Ort: Oberreichenbach
16.426 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#7

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

  Alt 22. Feb 2019, 13:26
kostenlos, nicht umsonst:
...mysql
Nur eingeschränkt.
Oracle hat eine spezielle Art des GPL-Interpreation, was MySQL dazu führt das man entweder seinen Quellcode offen legen muss oder für MySQL bezahlen muss.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von wjjw
wjjw

Registriert seit: 3. Aug 2017
Ort: Wiener Neustadt
29 Beiträge
 
Delphi 10.3 Rio
 
#8

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

  Alt 22. Feb 2019, 13:27
zu "Anwendung X läuft nicht"
Natürlich ist das so auch bei einem Server, ich vermute es ging hier darum, dass eine Anwendung eben kein Server sein sollte. Ein Server läuft ohne nennenswerte Userinteraktion vor sich hin, bei einer Anwendung (auf einem Deskopt) ist das wohl anders. Es geht einfach um Risiko Minimierung.
Es handelt sich ja nicht um einen „richtigen“ Server sondern nur um eine Anwendung, die Serveraufgaben „auch“ erledigen soll (in meinem Fall Kommunikation mit den Clients). Um die Daten zu speichern verwende ich eine DB (könnte auch Dateien verwenden).
Läuft die Hauptanwendung nicht, dann sollen die Clients auch nicht mehr kommunizieren können - ist ja so gewollt.

Zitat:
Welche DB
Wenn Du hier die DB Threads durchgehst, wirst Du immer wieder die gleichen Kandidaten finden
kostenlos, nicht umsonst:
firebird, postgres, mysql/maria
kommerziell:
interbase, mssql, oracle
Wie bei meiner Beschreibung erwähnt läuft das Hauptprogramm auf allen Platformen (nicht nur Windows). Daher denke ich mal das ich z.B. Oracle auf iOS nicht zum laufen bringe...
Werner Weiß
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
468 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#9

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

  Alt 22. Feb 2019, 13:38
Es hat keinen Sinn DMBS Funktionalität in einer Anwendung nachzubauen und schon gar nicht in einer Enduser Anwendung. Selbst die SAP ist froh, dass sie diese Hintegrundverbuchungsprozesse los ist und selbst die laufen in einer isolierten Serverapplikation. Viel mehr User als an deiner Anwendung angemeldet waren auf einem Host auch nicht gleichzeitig aktiv.

Solche Aufgaben erledigt an sich eine Middleware oder du baust die Fähigkeiten der DBMS auf der Business Ebene nach. Darunter leiden alle auf Nachrichten basierten Architekturen.

Was eine DB langsam macht ist der Overhead der Transaktionen und damit verbunden die Aufrechterhaltung der Konsistenz bspw... ACID.

Mal von den bereits genannten Vorschlägen abgesehen.

Du kannst einen Verbuchungsprozess machen der übermittelte Dateien einbucht. Das käme einer Nachricht nahe. Zum Zwecke der Verarbeitung kannst du einen Webserver hernehmen. Der Request an einen Webserver wird vor seiner Bearbeitung genauso in eine File geschrieben.

Mehr als eine Fire und Forget Nachricht die eine nice to have Information beinhaltet würde ich nicht direkt an solch eine Anwendung schicken.

---

SQLite ist ganz gut, wenn man Daten repliziert und viel liest oder lokal hält.

Hallo!

Ich habe ein Programm das bis dato im "Single-User" Modus läuft.
Nun soll das Programm auf Multi-User laufen - was bei mir folgendes heisst:
A) Im Hauptprogramm "X" arbeitet ein Benutzer (Windows, Android, iOS)
B) Die Companion-App "Y" läuft auf mehreren mobilen Gräten (Android, iOS, Windows)
C) Die mobilen Apps "Y" schicken Daten an das Hauptprogramm "X"
D) Alle Programme kommunizieren im lokalen Netzwerk (kein Internet oder Cloud)

Nun möchte ich nicht das Hauptprogramm "zu viel" durch die mobilen Apps blockieren und umgekehrt -> Threads.
Problem ist das ich als Datenbank SQLite einsetze (da es auf jeder Platform verfügbar).
Die Datenbankoperationen hab ich schon gekappselt.
Es gibt einige Techniken das umzusetzen, jedoch welche passt bei dem Fall am Besten? TWorker, Critical Sections, ...
Die Datenpakete, die ich von den mobilen Apps bekomme, sind nicht groß - im Prinzip einzelne Datensätze bis zu 50 an der Zahl.

Vielleicht hat ja jemand eine Idee oder ein ähnliches Projekt umgesetzt.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.234 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#10

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

  Alt 22. Feb 2019, 13:44
Zitat:
Wie bei meiner Beschreibung erwähnt läuft das Hauptprogramm auf allen Platformen (nicht nur Windows). Daher denke ich mal das ich z.B. Oracle auf iOS nicht zum laufen bringe...
Braucht es auch nicht, wenn man den Datenzugriff abstahiert.
Zitat von mkinzler:
GGf. zusätzlich den Datenzugriff per REST kapseln, für den Zugriff von mobilen Geräten ist das sowieso sinnvoll.
Die Speicherung der lokalen Daten kann dann ja in SQLite, FireBird embedded oder IBLite erfolgen.
Markus Kinzler
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:53 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf