Programmieren - alles kontrollieren 4.938 Themen, 20.667 Beiträge

Verfolgung starten Optionen

Server-Client-Anwendung mit MySql

Svenman_1 / 2 Antworten / Flachansicht Nickles

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

bei Antwort benachrichtigen
Eine echte Client-Server Anwendung wäre für mich Punkt 2. Auf dem Host, ... REPI
xafford Svenman_1 „Server-Client-Anwendung mit MySql“
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.
Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen