Client/Server Architektur realisieren - Ideen

[TheMiller]

Hallo,

ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen. Das Programm besteht aus einem Hauptprogramm mit mehreren Modulen/Plugins. Die Datenspeicherung übernimmt eine MySQL-Datenbank.

Da das Programm und dessen Plugins hauptsächlich mit Daten aus der DB arbeiten, benötigt jedes Programmteil eine Datenbankverbindung und muss mit dem DB-Server kommunizieren können.

Das hat natürlich zum Nachteil, dass pro Benutzer mehrere Datenbankverbindungen (eine pro Programmteil) geöffnet wird. Weiterer Nachteil ist, dass es zu schwer abfangbaren Problemen im Programm kommt (keine Reaktion etc.), wenn die Verbidung zur Datenbank verloren geht. Dies kann durch remote-Zugriff via VPN etc. öfter mal passieren.

Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben. Dieser läuft auf dem Windows-Server 24/7. Programme/Plugins können bauen eine TCP-Verbindung zum Dienst auf, senden ihm ein command (zB getTasks), der Dienst verbindet sich zur Datenbank, liest die Daten aus und sendet sie per tcp (hier meine ich Indy-TCP-Server/Client) an den Clientprozess zurück. Wenn keine Internetverbindung besteht, kann man das echt gut abfangen und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet. Alle Datenbankoperationen (hinzufügen, ändern, löschen) würden dann vom Dienst übernommen werden. Dies ist auch einfacher zu Warten.

Die Kommunikation zwischen Client und Dienst würde per Strings/Records stattfinden. Da wir OOP nutzen, würden die Daten eines Objekts in ein Record übergeben und dann zum Dienst übertragen werden, da man ja keine Objekte verschicken kann. Oder, wenn es in Delphi auch sowas gibt, dann ein serialisiertes Objekt (ähnlich zu json_encode in php).

Macht man das so? Was haltet ihr davon? Habt ihr Tipps dazu?

Danke im Voraus

[Dejan Vu]

Früher konnte man das noch direkt mit Delphi-Bordmitteln lösen, jetzt sollte das doch auch noch gehen. Stichwort: TRemoteDatamodule

Es gibt auch Drittanbieter, die das noch 1000x besser gelöst haben (RemObjects)

Erfinde das Rad nicht neu.

[Der schöne Günther]

Schau doch mal nach wann die erste JSON-Serialisierung in Delphi kam. War es nicht sogar 2009 oder 2010?

[Olli73]

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen.

Wenn du jetzt schon einen DB-Server einsetzt ist das doch bereits eine Client/Server-Anwendung; was du vorhast, wäre dann eine Multi Tier Architektur, oder liege ich da falsch?

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet.

Dann (mit 1 Datenbankverbindung) kannst du allerdings i.d.R. die Abfragen nur nacheinander ausführen. Das heißt, wenn ein Client eine Abfrage schickt, die z.B. 20 Sekunden benötigt, müssen alle anderen warten. Daher sollte man das "Multi Threaded" lösen und dazu brauchst du i.d.R. wieder mehrere Datenbankverbindungen, was aber auch nicht schlimm ist.

Gruß,
Olli

[TheMiller]

Danke für die Antworten.

Mutil Tier habe ich zwar schon öfter gelesen, mich aber nie darum gekümmert, was es ist.

Die Datenbank läuft i.d.R auf einem Linux-Server (MySQL).

Es ist richtig, dass die Verarbeitung dann nacheinander durchgeführt wird. Man könnte ja überlegen, die Anzahl der offenen Verbindungen auf 2 Stk. pro User zu beschränken. Immernoch besser, als wenn jedes Plugin eine offene Verbindung hält. Manchmal sind nämlich gleichzeitig 4 Plugins offen. Das macht bei 10 Usern - die die Anwendung regelmäßig nutzen - 40 Verbindungen. Ich dachte, es wäre besser, dies zu reduzieren und das alles zentral abwickeln zu lassen.

Der Dienst soll darüber hinaus noch andere zentrale Aufgaben übernehmen, die nichts mit der Datenbank zu tun haben.

Wichtig wäre mir halt auch das Abfangen auftretender Verbindungsprobleme, was über einen Dienst mit Kommunikation zum Client besser gehandlet werden könnte. Denke ich.

Ich habe ein wenig über TRemoteDatamodule gelesen. Verstehe das alles noch nicht so ganz. Wüsste aber auch nicht, wo die Vorteile sind. Wenn ich dem Indy-TCP-Server einen Command schicke, weiß er, was damit zu tun ist, läd die Daten aus der Datenbank (dazu nutze ich übrigens UniDAC), und gibt das json zurück via Indy-TCP. Geht es wirklich noch einfacher, oder habe ich einen Denkfehler?

Ihr seht - das ist noch neu für mich.

[TheMiller]

Ein kleiner Nachtrag noch, warum ich diese Architektur in Erwägung ziehe. Bin aber dahingehend für alles offen ;)

Der Server könnte so auch alle Clients mit aktivem Modul XY benachrichtigen, wenn sich Änderungen in ihm bzw. dem Datenbestand ergeben haben.

So könnten die Clients gleich die neuen Daten laden.

[Sir Rufo]

Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen :)

[TheMiller]

Genau das habe ich mir auch schon überlegt.

Nur leider soll der Dienst ja auch weitere, nicht-datenbankbezogene Aufgaben erledigen. Wie ich eben oben schrieb, soll er ja auch Nachrichten an die Clients schicken, wenn sich ein Datenbestand geändert hat, der gerade via Plugin von einem Client offen ist.

Auch soll sich der Dienst über die Benutzerverwaltung kümmern (wer ist mit welcher IP online, wer ist offline), kleiner Chat, Backup und einige weitere Funktionen aus dem Bereich der Textverarbeitung der Clients etc.

[fillibuster]

Hi,

Zitat:

Zitat von Sir Rufo (Beitrag 1282366)

Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen :)

... und hier das passende PHP Framework dazu: http://www.slimframework.com/. Habe ich genau für diesen Anwendungsfall sehr gute Erfahrungen mit gemacht.

Viele Grüße ....

[TheMiller]

Die Datenbankkommunikation könnten wir aber tatsächlich in eine PHP-Anwendung auslagern, da wir - zumindest Teilfunktionen - auch für andere Plattformen wie (na klar) iOS etc. planen. Da müsste man nur eine Stelle pflegen.

Dennoch bleiben die anderen Aufgaben übrig und die Benachrichtigung über neue Daten würde wieder schwerer zu realisieren sein. Ein Timer-Polling der Clients will ich eigentlich vermeiden.

Würde gerne so programmieren, dass man auch locker von außerhalb via VPN arbeiten kann, ohne, dass alles brechend langsam wird.

[Sir Rufo]

Wenn du eine Zwischenschicht da einziehst, dann kannst du gerade was die Performance angeht sehr schön skalieren, denn wo die Zwischenschicht sich die Daten herholt, weiß der Client nicht und muss er auch nicht entscheiden. Steigt die Anzahl der Abfragen, dann kommen im Hintergrund einfach ein paar mehr Slave-Datenbank-Kisten und die werden dann eben gefragt (Last-Verteilung).

Für die kontinuierliche Benachrichtigung gibt es weitere Möglichkeiten (z.B. MessageQueues), die dann auch von der Zwischenschicht bedient werden.

[mm1256]

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Hallo,

ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen. Das Programm besteht aus einem Hauptprogramm mit mehreren Modulen/Plugins. Die Datenspeicherung übernimmt eine MySQL-Datenbank.

Was ist denn daran derzeit "nicht" Client-Server?

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Da das Programm und dessen Plugins hauptsächlich mit Daten aus der DB arbeiten, benötigt jedes Programmteil eine Datenbankverbindung und muss mit dem DB-Server kommunizieren können.

Das hat natürlich zum Nachteil, dass pro Benutzer mehrere Datenbankverbindungen (eine pro Programmteil) geöffnet wird. Weiterer Nachteil ist, dass es zu schwer abfangbaren Problemen im Programm kommt (keine Reaktion etc.), wenn die Verbidung zur Datenbank verloren geht. Dies kann durch remote-Zugriff via VPN etc. öfter mal passieren.

Ich habe ein ähnliches Programm-Konzept mit meinem WWS: ein Hauptprogramm und dazu 18 Module, wo jedes seine eigene Datenbankverbindung hat. Das Ganze läuft schon seit über 14 Jahren auf über 800 Installationen. Bisher konnte ich diese von dir angesprochenen Nachteile nicht nachvollziehen. Entweder die Datenbank und der Server kann das, oder irgendwas läuft falsch.

Abgesehen von den vermeintlichen Nachteilen hat das Prinzip auch (daten-)sicherheitstechnische Vorteile. Wenn ein Client (ein Modul auf einem PC im Netz) abraucht (nicht mehr reagiert) dann hat das auf die übrigen Verbindungen überhaupt keinen negativen Einfluss. Der Server trennt diese einzige Verbindung, ohne dass die anderen Clients davon was mitbekommen.

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben.

Also einen Dienst der den Datenbank-Dienst (nichts anderes ist ja (d)eine Datenbank) mit Daten "füttert". Und wenn die CS-Verbindung abraucht, dann raucht die (Netzwerk-)Verbindung deines Dienstes zu den Clients auch ab. Ich kann da beim besten Willen keinen Vorteil erkennen. Höchstens den Schluss daraus ziehen: Wenn deine Datenbank und/oder deren Clients mit Verbindungsabbrüchen bis hin zu Stromausfällen im laufenden Betrieb nicht richtig umgehen können, dann liegt das Übel nicht am System, sondern an der Datenbank, oder dessen Programmierer der die Möglichkeiten der Datenbank nicht ausschöpft.

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Was haltet ihr davon?

Sorry, gar nichts.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1282374)

Was ist denn daran derzeit "nicht" Client-Server?

Umgangssprachlich wäre ein C/S auch ein N-Tier(N>2) System. Und wir wissen doch, was er meint. DJ-SPAM hat jetzt nicht um Nachhilfe in Sachen Nomenklatur gebettelt.

Zitat:

Ich kann da beim besten Willen keinen Vorteil erkennen.

Ich kann in einer Zwischenschicht besser auf Änderungen reagieren. Ich kann die eine exklusive Verbindung optimal nutzen. Die Verbindungsinformation ist nur an einer Stelle zu hinterlegen, Sicherheitskonzepte lassen sich wesentlich einfacher Umsetzen, nicht jede IT-Infrastruktur erlaubt es, von allen Clients eine Verbindung zu einem DB-Server herzustellen. Caching wäre auch noch eine lustige Option. Etc. Etc. Etc. Das sind jetzt nur die Vorteile, die mir sofort einfallen.

Zitat:

...Höchstens den Schluss daraus ziehen: Wenn deine Datenbank und/oder deren Clients mit Verbindungsabbrüchen bis hin zu Stromausfällen im laufenden Betrieb nicht richtig umgehen können, dann liegt das Übel nicht am System, sondern an der Datenbank, oder dessen Programmierer der die Möglichkeiten der Datenbank nicht ausschöpft.

Äh, hüstel. Schon mal was von instabilen Providern gehört? Schon mal in Asien gewesen? Schon mal einen Zusammenbruch des QoS bei einer TCP-Verbinduing mitgemacht, obwohl das laut OSI-Modell gar nicht geht? Es liegt nicht immer an der Datenbank und auch nicht am Programmierer... Und ich verstehe auch nicht, weshalb Du hier so rumzottelst.

Sachlichkeit und ein wenig mehr Grundwissen über C/S und N-Tier-Technologien sowie deren Vor- und Nachteile wäre wirklich angebracht. Nur weil dein Gurken :mrgreen: System seit 50 Jahren läuft, heißt das ja nicht, das das nicht besser, schlanker und moderner geht.

Wie und wo speicherst Du eigentlich die Verbindungsdaten zum Server? Also Login und Kennwort? Auf jedem Client? Hö. Viel Spaß mit Leuten, die Lust haben, den Zugang zu knacken. Ist popeleinfach, schätze ich. Bei einem N-Tier-System ist das dann schon etwas schwieriger.

Das nur mal so am Rande.

[mm1256]

Jetzt hast du eindrucksvoll beschrieben, dass du ein Oberchecker bist und ich eine rumzottelnde NULL mit popeleinfachem .... Vielen herzlichen Dank für die Aufklärung.

[TheMiller]

Angenommen, ich würde micht entscheiden, dass wir tatsächlich eine Server-Anwendung in Form eines Windows-Dienstes schreiben, welches Konstrukt sollte ich bevorzugen?

Ich dachte die ganze Zeit an einen Indy-TCP-Server/Client. Dem Server werden commands geschickt (ähnlich wie Parameter-Übergaben bei Webseiten). Diese liest er aus und führt die jeweilige Aktion durch.

Gibt es bessere/professionellere Wege als den Indy-TCP-Server? Das System sollte jedoch recht simpel gestaltet werden. Ein riesen Framework ist glaube ich nicht von nöten. Es werden bestimmt nie mehr als 30 Clients gleichzeitig mit dem Server kommunizieren. Wie viel hält der TCP-Server eigentlich aus?

Die Umsetzung war ja auch teil meiner Frage. Wie gesagt, habe sowas noch nie umgesetzt, außer micht mit einer Datenbank verbunden. Das zähle ich jetzt aber nicht mit ;)

Ich habe mich zwar noch nicht entschieden, aber bis jetzt ist die Dienste-Methode als Zwischenschicht im Rahmen des Möglichen.

[mkinzler]

Ich würde mir nicht zutrauen, in akzeptabler Zeit, das Rad "besser" neu zu erfinden. ;)

[Dejan Vu]

Schau dir mal RemObjects an. Die haben doch alles.
Oder die Delphi-eigenen Komponenten, damit geht das doch auch.
Oder die -sehr generisch- die Middleware-Suite von FPiette.

Nochmal: Mach das nicht selbst, das lohnt nicht (außer, ihr habt sonst nichts zu tun).

Zitat:

Zitat von mm1256 (Beitrag 1282386)

Jetzt hast du eindrucksvoll beschrieben...

Das war nicht meine Absicht, aber wer austeilt, sollte auch einstecken können, findest Du nicht auch?

[mjustin]

Zitat:

Zitat von DJ-SPM (Beitrag 1282388)

Ich dachte die ganze Zeit an einen Indy-TCP-Server/Client. Dem Server werden commands geschickt (ähnlich wie Parameter-Übergaben bei Webseiten). Diese liest er aus und führt die jeweilige Aktion durch.

Eine einfache Architektur wäre ein zentraler Windows Server mit einem auf dem Indy HTTP Server basierenden Service.

Darin würde ein MySQL Connection Pool dafür sorgen, dass immer frische, knusprige Datenbankconnections vorrätig sind.

Die Clients würden dann (ebenfalls Indy basierte) HTTP Verbindungen öffnen, Requests mit Parametern senden und die Daten dann als Anwtorten zum Beipisle JSON codiert erhalten.

Gegenüber reinem TCP hat HTTP einige Vorteile. Es können ständig geöffnete Verbindungen verwendet werden (keep-alive, HTTP 1.1) und über long polling kann eine Verbindung auch aktiv Daten vom Server erhalten ('Server-Push'). Dazu würde dann allerdings eine separate Connection benötigt, nicht die in der die normalen blockierenden Daten-Requests stattfinden.

p.s. natürlich sind bestehende Frameworks, wenn sie denn genau zu den Anforderungen und Rahmenbedingungen passen, sehr zu empfehlen. Nur bei kleinen bis mittleren Systemen würde ich eine Eigenentwicklung erwägen. Oder wenn man "experimentierfreudig" zu seinen soft skills zählt :)

[TheMiller]

Zitat:

Zitat von mkinzler (Beitrag 1282389)

Ich würde mir nicht zutrauen, in akzeptabler Zeit, das Rad "besser" neu zu erfinden. ;)

Wie habe ich das jetzt zu verstehen? Meinst du, man kann den Indy-Server benutzen und muss nicht zu was ganz eigenem greifen, oder denkst du, man sollte den Indy-Server nicht nutzen und lieber ein (großes?) Framework nutzen? Und wenn Framework - an welches denkst du?

DataSnap soll sehr langsam und fehlerbehaftet sein. Und die Geschichte mit TRemoteDatamodule hört sich gerade etwas kompliziert an.

Roter Kasten:
Danke für die weiteren Nachrichten. Ich muss mir mal die Vorteile / Unterschiede zwischen einer eigenen Lösung und den vorgeschlagenen Frameworks anschauen. Derzeit denke ich, dass wir nicht viele Funktionen brauchen, außer den Transport von json-"Objekten". Die HTTP-Methode hört sich auch sehr gut an.

Das Rad will ich keinesfalls neu erfinden. Dazu fehlt die Zeit. Nur abwägen zwischen dem Kauf neuer Komponenten (was mittlerweile ordentlich Geld kostet), den Funktionen die wir nutzen werden, und Boardmittel benutzen.

[mkinzler]

Ich meinte, Du solltest Dir vorhandene Lösungen ansehen und dann entscheiden, ob es wirklich sinnvoll ist selber Zeit zu investieren.

https://mikejustin.wordpress.com/201...n-with-delphi/
http://www.realthinclient.org/details/
http://www.tmssoftware.com/site/remotedb.asp
http://www.overbyte.be/frame_index.html
http://www.dataabstract.com/da/

[mm1256]

Zitat:

Zitat von Dejan Vu (Beitrag 1282390)

Das war nicht meine Absicht, aber wer austeilt, sollte auch einstecken können, findest Du nicht auch?

Da liegst du in mehrerlei Hinsicht falsch. Ich habe nicht ausgeteilt, sondern du. Wenn du der Meinung bist, das hier ist eine "Austeilstation" dann ist das zu tolerieren eine Angelegenheit der Mod's. Der TE hat auch nicht nach Asien oder instabilen Providern gefragt. Das sind Argumente die du dir selber aus der Nase gezogen hast, um deinen Kommentar zu rechtfertigen. Mit Sachlichkeit hat das jedenfalls nicht viel zu tun.

Ich habe lediglich meine Meinung kund getan. Vielleicht in einer etwas "direkten Formulierung", doch was soll daran falsch sein. Es geht doch - um zur urspünglichen Frage zurück zu kommen

Zitat:

Zitat von DJ-SPM

...Weiterer Nachteil ist, dass es zu schwer abfangbaren Problemen im Programm kommt (keine Reaktion etc.), wenn die Verbidung zur Datenbank verloren geht. Dies kann durch remote-Zugriff via VPN etc. öfter mal passieren.

...und da bin ich nach wie vor der Meinung, dass eine Zwischenschicht das Problem nicht lösen kann und wird, denn wenn (in der jetzigen Situation) die Verbindung zur Datenbank verloren geht, dann wird danach eben anstelle zur Datenbank die Verbindung zur Zwischenschicht verloren gehen. Wo ist da (für den Client) der Unterschied oder der Vorteil? Ich sehe keinen. Zumindest keinen, den eine normale Datenbank (Stichwort failsave transactions) nicht auch handeln kann. Eine Zwischenschicht macht doch nur Sinn, wenn ich unterschiedliche Clients (Workstations, WEB-Clients, mobile Geräte) zusammenführen muss. Ich lasse mich aber gerne eines Besseren belehren.

[mjustin]

Zitat:

Zitat von mm1256 (Beitrag 1282400)

...und da bin ich nach wie vor der Meinung, dass eine Zwischenschicht das Problem nicht lösen kann und wird, denn wenn (in der jetzigen Situation) die Verbindung zur Datenbank verloren geht, dann wird danach eben anstelle zur Datenbank die Verbindung zur Zwischenschicht verloren gehen. Wo ist da (für den Client) der Unterschied oder der Vorteil? Ich sehe keinen. Zumindest keinen, den eine normale Datenbank (Stichwort failsave transactions) nicht auch handeln kann.

Naja, ein paar Vorteile fallen mir da schon ein:

* keine Datenbank-Clientinstallation auf den Clients erforderlich => was nicht da ist, kann auch nicht ausfallen oder falsch konfiguriert werden
* keine datenbankspezifische Programmierung (Transaktionsbehandlung) im Client => Komplexität nur noch im Middle-Tier, die ohne Roll-out neuer Clients gepflegt werden kann
* durch asynchrone Requests (Message Queues) können DB-Aktionen die zum Beispiel während einer Downtime der Datenbank nicht möglich sind, zeitversetzt erfolgen. Ein Middle-Tier System kann auch Caching dazu einsetzen, dass Clients während eines Datenbankausfalls noch eingeschränkt weiter arbeiten können.

Hochverfügbarkeit kann man in einem klassischen Client/Server System nur mit höherem Aufwand erreichen.

[Dejan Vu]

Bei einem Kunden ist es nicht möglich und nicht gewollt, vom Client aus direkt auf die DB-Server zuzugreifen. Eine Zwischenschicht löst das Problem, ohne das die Sicherheitspolitik zur Disposition steht. Oft gemacht (mit Delphi-Bordmitteln).

Zitat:

Zitat von mm1256 (Beitrag 1282400)

Der TE hat auch nicht nach Asien oder instabilen Providern gefragt. Das sind Argumente die du dir selber aus der Nase gezogen hast

Eigentlich nicht, sondern Belege aus meiner Arbeit. Ich könnte Dir da auch noch tolle Beispiele aus USA benennen, was die dort teilweise unter einem stabilen Netzwerk verstehen. Ich bin halt rumgekommen und kann was erzählen. Tut mir leid, soll ich mein Wissen für mich behalten? Vor allen Dingen, wenn ein naseweiser Neunmalkluger meint, alles besser zu wissen? Nein, Du bist damit natürlich nicht gemeint.

Zitat:

...und da bin ich nach wie vor der Meinung, dass eine Zwischenschicht das Problem nicht lösen kann und wird, denn wenn (in der jetzigen Situation) die Verbindung zur Datenbank verloren geht, dann wird danach eben anstelle zur Datenbank die Verbindung zur Zwischenschicht verloren gehen.

Deine Meinung in Ehren, aber so einfach ist das vielleicht doch nicht:

Wie reagierst Du denn bei deiner Lösung, wenn der Server ausfällt und der Backup-Server nun einspringen muss (andere IP)? Dann rennst Du doch zu allen Clients und änderst die Konfiguration, oder wie löst Du das sonst? Doch nicht etwa über eine im Netz stehende Konfigurationsdatei? :lol:

Na ja, wenn du von deiner Lösung überzeugt bist, dann ist das ja ok. "Never change a running system". Aber wenn das System vom TE nicht gut läuft, sind erprobte und etablierte Alternativen ('N-Tier', Proxy) doch wohl besser angebracht, als ein: "Bringt doch nix". Mach doch erst einmal Erfahrungen mit mehrschichtigen Anwendungen. Entweder wirst Du deine Meinung bestätigt sehen, oder nicht: Gewonnen hast Du dann auf jeden Fall.

[mm1256]

Zitat:

Zitat von Dejan Vu (Beitrag 1282433)

Bei einem Kunden ist es nicht möglich und nicht gewollt, vom Client aus direkt auf die DB-Server zuzugreifen....

Von diesem Sachverhalt hat der TE bisher nichts erwähnt. Es ging um "mehrere Datenbankverbindungen" und um "schwer abfangbare Probleme bei Verbindungsabbrüchen". Da der Thread aber nicht unter "Klatsch und Tratsch" läuft, werde ich mich jetzt aus dem Thema raus halten, weil unsachliche Beiträge meiner Meinung nach nicht zweckdienlich sind.

[humbuck]

Es ist ja nun noch nicht genau zu ersehen, für was für eine Lösung du dich nun entschieden hast, aber du solltest dich vielleicht mit einer Kombilösung anfreunden.

Deine Verwaltung deiner wichtigsten Daten kannst du doch durchaus 'sicher' und unabhängig lösen:

Zitat:

Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen

Halte ich persönlich bei der vorherrschenden Serverarchitektur als absolut sinnvoll.

Wenn du dann ergänzend für nicht 'so wichtigen' Dienste für deine Kunden/User eine Multithread-Verbindung á la TCP-Client-Server einrichtest, schaffst du dir eine passable Lösung für deine Probleme. Selbst die Datensicherung via Netz/Internet lässt sich dann verwirklichen.
Client-seitig solltest du dann vielleicht ein Programm-Update für deine Kunden in Erwägung ziehen, um Einzelverbindungen aus den Plugins für die TCP-Client-Server-Lösung in dein Hauptmodul zu verlagern...

Das Rad nicht neu erfunden und doch verwendbar.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1282436)

Es ging um "mehrere Datenbankverbindungen" und um "schwer abfangbare Probleme bei Verbindungsabbrüchen".

Seufz, man wird wohl noch bei einer allgemeinen Diskussion um Vor- und Nachteile diese Punkte erwähnen dürfen.

Zitat:

werde ich mich jetzt aus dem Thema raus halten

Oh, bitte.

Zitat:

Zitat von humbuck (Beitrag 1282457)

Zitat:

..klatsch dir da mit PHP ein REST drauf ...

Halte ich persönlich bei der vorherrschenden Serverarchitektur als absolut sinnvoll...

Auch hinsichtlich der allgemeinen Erweiterbarkeit (thin client, mobile) sicherlich eine sehr gute Lösung.

[Mavarik]

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben. Dieser läuft auf dem Windows-Server 24/7. Programme/Plugins können bauen eine TCP-Verbindung zum Dienst auf, senden ihm ein command (zB getTasks), der Dienst verbindet sich zur Datenbank, liest die Daten aus und sendet sie per tcp (hier meine ich Indy-TCP-Server/Client) an den Clientprozess zurück. Wenn keine Internetverbindung besteht, kann man das echt gut abfangen und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet. Alle Datenbankoperationen (hinzufügen, ändern, löschen) würden dann vom Dienst übernommen werden. Dies ist auch einfacher zu Warten.

Interessant... Ich arbeite zur Zeit an einer ähnlichen Lösung aufgrund von ähnlichen Problemen.
Mein Ansatz ist zwar etwas anders aber läuft aufs gleiche hinaus.

Clientseitig nur mir meiner Schicht reden ohne eine Datenbank Komponente. Somit kann ich in 2 Sekunden meine Software von Datenbank A auf Datenbank B umstellen uvm. Indy ist entgegen von overbyte meine Wahl, da die Overbyte Sourcen nicht Android/iOS kompatible sind. (Nach meinen Wissen, obwohl ich ein Overbyte-Fan bin).

Wichtig für mich ist auch ein "Shoot & Forget" ich mache 10000 Posts und meine App arbeitet sofort weiter als währen die Daten schon in der Datenbank angekommen... Die Zwischenschicht kann dann in einem netten WorkerThread die Daten "in Ruhe" weg schreiben und nur ggf. im Fehlerfall mir einen Callback schicken. (Vereinfacht)

Daher je einen Teil der Zwischenschicht in jedem Client und den anderen Teil zentral/dezentral. Hier können auch mehrere Server dann Synchronisiert werden.

Mavarik

PS.: Momentan "bastel" ich noch an einem Konzept für eine SELECT bla JOIN bla Umsetzung.

[sh17]

Also ich würde auch eine Zwischenschicht einbauen. Wir haben das bei einem Produkt auch so gemacht, mit der RemObjects SDK und Indy (Den DataAbstract-Überbau brauchst Du nicht)

[Mavarik]

Zitat:

Zitat von sh17 (Beitrag 1282740)

(Den DataAbstract-Überbau brauchst Du nicht)

Für mich ist das eine Motivation die Zwischenschicht zu programmieren.

Jeder spricht von:
- Designpatten's
- dependency injection
- MVVM
- uvm.

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

Mavarik

[TheMiller]

Hallo zurück ;)

Vielen Dank für die weiteren Antworten. Ich habe erst Sonntag entdeckt, dass neue Beiträge geschrieben wurden und seitdem leider keine Zeit mehr gehabt zum Antworten - aber zum Nachdenken!

----
Aber eines Vorweg: Meine Themen stellen oft auf abstrakte Fragen, Grundsätze, Aufbauftechniken etc. ab. In diesem Rahmen ist es durchaus gewollt, dass andere Leute ihre Erfahren und Bedenken teilen, weitere Vor- und Nachteile nennen/entwickeln und so mir und anderen einen erweiterten Blick auf die Themen zu geben. Denn niemand denkt an alle Eventualitäten. Ob das nun sinnvoll ist, kann ja jeder für sich entscheiden. Wenn es nun aber mit dem eigentlichen Thema garnichts mehr zu tun hat, tja, dann ist es wirklich fehl am Platze.

Aber ich schätze die DP eben gerade dafür, dass man nicht nur Stumpf die Frage beantwortet, sondern eben wie in einem Gespräch unter Kollegen auf weitere Sachen hingewiesen wird oder ein gänzlich anderer Vorschlag gebracht wird, weil es anders eben besser ist als ursprünglich gedacht.

Ich habe das Programmieren damals in der Schule angefagen, heute programmiere ich durchaus erfolgreich. Ich habe keine Ausbildung und kein Studium in der Programmierung. Alles nur durch Eigenstudium und die Hilfe der DP.

----

So. Ich werde definitiv eine Zwischenschicht einbauen. Es hat wirklich viele Vorteile. Sie wird höchstwahrscheinlich in PHP erstellt, also eine REST-API. Passt auch gut, da ich eine solche schon mehrfach umgesetzt habe.

Zusätzlich werde ich einen Server und einen Client brauchen. Ich denke, dafür reichen wirklich die Indys. Ich habe mir das nun folgendermaßen gedacht - da würde ich gerne wissen, ihr das die Methode für "okay" empfindet:

* Auf dem Windows-Server läuft in einem Windows-Dienst der Indy-TCP-Server.
* Der TCP-Client verbindet sich mit dem Server und sendet einen String in der Form: "/db/getObject/[objectname]/[db-id]".
* Der Server fragt in der API nach und sendet den json-String zurück.

Mir geht es hauptsächlich darum, ob die Kommandos in der o.g. Form eine gute Idee sind, oder ob ich ein anderes System/Format nutzen sollte. Dieser String könnte auch durchaus anders aussehen, z.B. so: "/user/registerOnline/192.168.1.6".
Oder man sendet gleich ein Record bzw. json-array. Es ist halt erstmal das Problem da, dass nicht absehbar ist, wie viele Parameter übergeben werden müssen, geschweige denn ganze ObjectLists.

Das sind so meine jetzigen Überlegungen. Nehmt gerne Stellung dazu!

Danke im Voraus!

[p80286]

Zitat:

Zitat von Mavarik (Beitrag 1282743)

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

DAS soll der Sinn einer "Zwischenschicht" sein?
Eine "feste" Verbindung zur Datenbank in einer Anwendung?
Das scheint mir genauso sinnvoll wie hart kodierte Dateinamen.

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1282788)

Zitat:

Zitat von Mavarik (Beitrag 1282743)

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

DAS soll der Sinn einer "Zwischenschicht" sein?
Eine "feste" Verbindung zur Datenbank in einer Anwendung?
Das scheint mir genauso sinnvoll wie hart kodierte Dateinamen.

Gruß
K-H

Nein, nicht nur aber eben auch. Es wird entkoppelt und man hat damit weniger Abhängigkeiten (z.B. von der Datenbank-Komponente Fröhlichsein mit Fluxkompensator und Ventilator, aber nur bei linksdrehendem Joghurt).

[Mavarik]

Zitat:

Zitat von p80286 (Beitrag 1282788)

Zitat:

Zitat von Mavarik (Beitrag 1282743)

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

DAS soll der Sinn einer "Zwischenschicht" sein?
Eine "feste" Verbindung zur Datenbank in einer Anwendung?
Das scheint mir genauso sinnvoll wie hart kodierte Dateinamen.

Gruß
K-H

hmm eigentlich hatte ich

Zitat:

Zitat von Mavarik (Beitrag 1282743)

Endlich nicht mehr...

Geschrieben...

[Mavarik]

Zitat:

Zitat von DJ-SPM (Beitrag 1282785)

So. Ich werde definitiv eine Zwischenschicht einbauen. Es hat wirklich viele Vorteile. Sie wird höchstwahrscheinlich in PHP erstellt, also eine REST-API. Passt auch gut, da ich eine solche schon mehrfach umgesetzt habe.

...

Mir geht es hauptsächlich darum, ob die Kommandos in der o.g. Form eine gute Idee sind, oder ob ich ein anderes System/Format nutzen sollte. Dieser String könnte auch durchaus anders aussehen, z.B. so: "/user/registerOnline/192.168.1.6".
Oder man sendet gleich ein Record bzw. json-array. Es ist halt erstmal das Problem da, dass nicht absehbar ist, wie viele Parameter übergeben werden müssen, geschweige denn ganze ObjectLists.

Wie sieht dann Dein Daten-Flow aus...

1. Optimierte Routine in Deiner Anwendung.
2. Umsetzen/Parsen in einen String.
3. String wieder als Bytes per TCP senden
4. Bytes wieder in String konvertieren
5. String auseinander nehmen
6. Routine um aus dem String eine Anfrage zu kodieren
7. Umsetzen in JSON
8. Anfrage an PHP (oh grusel)
9. PHP Interpretiert die JSON Anfrage
10. Wieder SQL daraus machen
11. Am Server per TCP anfragen

Und dann das ganze wieder zurück?

Sehen wir mal von meine Abneigung zu PHP ab... Stringanalysen sind immer langsam und Du hast zu viele Konvertierungen.
SQL ist mir schon nicht kompakt genug... Also Übertragungen und Kommandos so knapp wie möglich halten... Besonders wenn Du diese sowieso
per TCP Übertragen willst.

Absender, Kommando, SeekNr, DatenbankID sind bei mir 7 Byte... Wenn man jetzt noch die MTU und ggf. noch für das P2P Protokoll die Daten berücksichtig, ergeben sind 1452 Bytes für Nutzer Daten.
Das ist meine Größe für eine optimale Datenübertragung von mehreren Kommandos...
Aber vielleicht optimiere ich an dieser Stelle auf ein bisschen weit...
Also vergiss den Absatz. :oops:

Mavarik

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1282837)

Stringanalysen sind immer langsam und Du hast zu viele Konvertierungen.
SQL ist mir schon nicht kompakt genug...

Ich glaube, Du schraubst am falschen Ende: Ob eine Query 30 oder 100 Zeichen lang ist, sollte nie einen Einfluss auf die Performance haben. Und wenn, dann komprimiere die Kommunikation einfach, wobei das Komprimierung und Dekomprimieren ja auch Zeit kostet...
Und ob ein Parser 0.1 ms oder 1.5ms zum Analysieren des Kommandos benötigt, ist jetzt auch nicht so entscheidend.

Zitat:

Also Übertragungen und Kommandos so knapp wie möglich halten...

Richtig, aber aus einem ganz anderen Grund: Komplexität. Wozu von A, nach B und dann nach C konvertieren und umschrubseln, wenn man es gleich von A->C machen kann.

Deine Überlegungen sind grundsätzlich nicht falsch, aber hier vermutlich deplaziert, wie Du schon festgestellt hast. Bei einer Messdatenerfassung in Echtzeit würde ich dich allerdings konsultieren ;-)

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1282849)

Deine Überlegungen sind grundsätzlich nicht falsch, aber hier vermutlich deplaziert, wie Du schon festgestellt hast. Bei einer Messdatenerfassung in Echtzeit würde ich dich allerdings konsultieren ;-)

Naja... Würden "alle" ein bisschen die Geschwindigkeit im Kopf behalten bräuchten wir nicht immer schnellere PC's

Zugegeben... Manchmal ist es egal ob etwas doppelt so lange braucht. I.d.R. wartet die Software sowieso auf die nächste Eingabe des Benutzers.
Aber wenn eine Aktion schon eine Sekunde dauert - dann fängt es an zu nerven...
Beste Beispiel Du klickst auf einen Button und nix passiert. Nur weil die Routine dahinter keine Ausgabe hat oder den Button nicht sofort Disabled.

Also besonders in den Basis-Routinen sollte man immer ein Augenmerk auf die Performance halten.

Da gehören die Datenbankzugriffe klar mit rein. Daher drehen sich immer Sand-Uhren.

Dummes Beispiel:
Wäre doch schön, wenn ein Programm zum Beispiel bei Aktualisierungen von immer wieder aufgerufenen Listen die ersten 50 Einträger immer aktuell im Speicher hat.
Wenn der Benutzer die Liste aufruft - Schwupdi... Liste da! Rest wird - im Thread - nachgeladen.
- wie gesagt blödes Beispiel - aber ich denke die Idee ist ausbaufähig.

Mavarik

[DeddyH]

Vorsicht vor Optimierungen

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1282935)

Würden "alle" ein bisschen die Geschwindigkeit im Kopf behalten bräuchten wir nicht immer schnellere PC's

Einerseits.

Zitat:

Zitat von DeddyH (Beitrag 1282946)

Vorsicht vor Optimierungen

Andererseits.

Richtig ist, das es seit Jahren eine Vollpfostenmentalität gibt, die auf kompletter Unwissenheit und Borniertheit beruht und mit dazu beiträgt, das Bandbreiten und CPUs immer breiter schneller und tiefergelegt werden müssen.

Nachdenken bzw. ein Bewusstsein für überflüssigen Schnickschnack ist aber wichtig, finde ich.

Aber -mal wieder- Themaabdriftung.

[Sir Rufo]

Zum Thema:

Wofür soll der Windows-Dienst mit dem TCP-Server benutzt werden? Der ist mMn völlig überflüssig.

Man nehmen einen MessageQueue-Server seiner Wahl und fragt dort nach Nachrichten. Achtung, nur in einem separaten Thread, denn wenn nichts in der Queue ist, dann dauert diese Abfrage ein Weilchen.

Ist etwas in der Queue, dann bekommt man auch prompt die Antwort, wirft diese dann in der Anwendung in die Runde und wartet auf/holt sich die nächste Nachricht.

Der Rest geht mit der REST-API.

[TheMiller]

Moin!

Zitat:

Zitat von Sir Rufo (Beitrag 1282975)

Wofür soll der Windows-Dienst mit dem TCP-Server benutzt werden? Der ist mMn völlig überflüssig.

Ja, da gebe ich dir zwar Recht. Der Server soll aber noch andere Dinge übernehmen, als nur die DB-Anbindung zu verwalten. Ich möchte einen kleinen Realtime-Chat realisieren, eine eigene Datensicherung nur für den Notfall, Benachrichtigungen über den Online-Status der Benutzer etc. Ein weiteres Beispiel: Benutzer 1 - 4 haben das Plugin A offen. Benutzer 1 ändert jetzt einen Eintrag. Der Server soll dann gleich alle anderen Benutzer (2-4) benachrichtigen, dass neue Daten vorliegen, damit dort die Listen neu geladen werden können.

Diese und andere kleine Aufgaben soll der Server bewerkstelligen. Ich denke, es ist nicht verkehrt, einen solchen zu implementieren. Zur Kommunikation bin ich jetzt gedanklich dabei stehengeblieben, ein Record zu versenden. Ist das okay?

Das Record soll mindestens den Timestamp, Absender und die Anfrage (json_string) beinhalten. Mir fällt leider nichts anderes als ein json_string ein. Und da sehe ich ein Problem:

Manchmal muss es sein, dass 500+ Einträge aus der DB geladen werden. Jeder Eintrag ist ein Objekt - sagen wir mal, ein Adressen-Objekt. Diese Liste nun in einen json-String zu konvertieren dürfte ziemlich aufwendig / unperformant sein, oder? Welche Möglichkeit gibt es noch, Objekte/Objectlists über das Netzwerk zu versenden?

Danke!