Nickles › Forum › Software › Programmieren - alles kontrollieren

Programmieren - alles kontrollieren 4.940 Themen, 20.676 Beiträge

Server-Client-Anwendung mit MySql

Svenman_1 am 21.01.2009, 10:44 / 2 Antworten / Baumansicht

Hallo!

Ich hab eine Frage!
Ich möchte ein Server Client Programm schreiben, dass Kunden verwalten kann und das im Netzwerk läuft.

Ich kann mich aber nicht entscheiden, ob

1. Ich die User(Sehr wenige, vielleichtt 4-5) übers Netzwerk direkt auf die Datenbank zugreifen lasse ODER

2. Ob ich nur die Server Software auf die Datenbank loslasse und er dann die Anfragen annimmt und die Ergebnisse weitergibt, sodass immer nur einer auf der DB rummacht(Also im Prinzip ein eigenes "Protokoll" schreiben)

Was ist die sauberere Variante?

Gruß Sven

REPI

Svenman_1 „Server-Client-Anwendung mit MySql“

22.01.2009, 18:50 Optionen

Eine echte Client-Server Anwendung wäre für mich Punkt 2.

Auf dem Host, auf welchem die DB liegt (muss aber nicht sein) läuft ein (mehrere) Server, welche(r) mit Requestoren auf der Clientseit kommunizieren.
Alle Anfragen zu DB kommen immer über den Server auch werden Datenoperationen und Datenänderungen in der DB immer durch die Serversoftware durchgeführt. Der Client dient nur als Eingabe- und Ausgabemodul und stellt das Geschehen entsprechend grafisch dar.

Ist aber sicherlich mit wesentlich mehr Aufwand verbunden, als Variante 1.

xafford

Svenman_1 „Server-Client-Anwendung mit MySql“

24.01.2009, 11:04 Optionen

Deine Frage kann man so nicht beurteilen, denn für beides gibt es Pro und Contra, was besser ist hängt vornehmlich von der Art der Anwendung ab.

Ich will mal verschiedene Pro und Contra aufzählen:

Punkt 1 - Pro:

Du musst dich nicht um die Verwaltung gleichzeitiger und konkurrierender Zugriffe kümmern, das macht die Datenbank
Dieser Ansatz ist im Normalfall performanter, als noch einmal eine Zwischenschicht einzuführen
Du musst nur die Client-Anwendung warten
Die Entwicklungszeit wird kürzer
Du hast weniger Fehlerquellen
Prinzipiell reicht auf den Clients ein ODBC-Treiber, um auch mit anderen Frontends auf der Datenbank zu arbeiten (Access, Excel, MySQLFront etc.)

Punkt 1 - Contra:

Das System ist weniger flexibel und portabel. Bei einer Migration zu einem anderen DBMS oder einer neuen Version musst Du dafür sorgen, dass alle Client-Anwendungen mit aktualisiert werden
Du kannst nur die Zugirffsrechte und Sicherheitsfunktionen der Datenbank nutzen (unbedingt getrennte Datenbanknutzer vorsehen)
Alle weitergehenden Sicherheitsfunktionen und Filter müssen auf den Clients erfolgen
Experimentierfreudige Nutzer können direkt gefährliche Queries an die Datenbank absetzen, einziger Schutz sind dann die einzelnen Nutzerrechte
Daten zwischen den Clients können nur über die Datenbank ausgetauscht werden, keine zentrale Instanz um den Status zu wahren
Die Clientanwendungen werden sehr komplex

Punkt 2 - Pro:

Weitaus flexibler, Du kannst Protokoll und Anwendungslogik komplett von der Datenbank trennen und bei Modularisierung jederzeit die Datenbank wechseln und musst nur den Serverprozess ändern
Du kanst eigene erweiterte Zugriffsrechte und komplexe Funktionen implementieren
Du überträgst keine rohen Queries die jemandem einen Ansatzpunkt für Manipulation (auch versehentlich) geben
Du kannst einen zentralen Status erhalten und Kommunikation zwischen den Clients über den Serverprozess ermöglichen
Du kannst einen zentralen Update-Prozess für neue Programmversionen gleich integrieren
Zentrale Filter und Zugriffsbeschränkungen sind vor Manipulationen auf den Clients sicher und für alle Clients identisch, egal von der Programmversion
Dein Serverprozess kann direkt auf die C-API von MySQL zugreifen und so sogar effizienter sein, als rohe Queries an das DBMS zu schicken

Punkt 2 - Contra:

Du musst ein eigenes Protokoll entwickeln
Die Gefahr für Programmehler steigt
Du hast einen höheren Entwicklungsaufwand
Du hast einen höheren Wartungsaufwand
Du beschränkst die Kommunikationsmöglichkeit mit der Datenbank auf deine Anwendung, ODBC geht nicht mehr (kann Vorteil, aber auch Nachteil sein)

Das ist jetzt nur eine unvollständige Sammlung, halt eben das was mir spontan einfiel. Prinzipiell ist es jedoch so, dass eine eigene Serveranwendung immer mehr Sinn macht, je größerdie Wahrscheinlichkeit wird dass die Nutzung in Zukunft steigt (mehr Clients) und je unsicherer das Umfeld wird (also je weniger Vertrauen Du in die Anwender hast).

Es ist aber nicht so, dass Du ein für allemal auf einen Ansatz festgelegt bist. Wenn Du deine Clientanwendung in Schichten aufbaust und eine klare Trennung nach dem MVC-Modell einhältst, so kannst Du mit einer Anwendung beginnen, die direkt auf der Datenbank arbeitet und bei bedarf später den Kommunikationsstapel von direkter Datenbankkommunikation auf dein eigenes Protokoll umstellen, ohne den View-Teil ändern zu müssen. Den Teil für Anwendungs- und Datenlogik kannst Du dann für die Serveranwendung weiternutzen, nur der Teil für den Datenaustausch (das Protokoll) muss dann komplett neu entwickelt werden.