Client/Server Architektur realisieren - Ideen

**mm1256**

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 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 von mm1256:

...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.

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 von mm1256:

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?

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 von Dejan Vu:

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.