Datenbankaufbau über VPN

[murat1895]

Hallo zusammen,

ich habe folgendes vor:

Clients bauen über ein UMTS-Netz einen VPN-Tunnel mit dem Firmennetz auf. Im Firmennetz liegt eine Datenbank. Auf diese Datebank sollen die Clients lediglich schreiben. Nich lesen, löschen oder Datensätze verändern können.

Nun zur Frage, ist es sinnvoller eine direkte Verbindung zwischen Client und Datenbank aufzubauen oder einen zwischenschritt in dem nur die reinen Daten in das Firmennetz übertragen werden und nachdem die Daten separat in die Datenbank eingelesen werden. Es geht mir hierbau um die Geschwindigkeit. Der Client soll sich alle 4 Std. mit der Datenbank verbinden und schreiben oder die reinen Daten übertragen.

Habe in dem Bereich leider noch keine große Erfahrung gemacht.

Danke!

[Schiller256]

In meinen Augen kommt es ein wenig auf die zu übertragenden Daten an. Wenn es große Datenmengen sind dann wäre eine Übertragung einer Datei besser. Denn du kannst die Datei vor der Übertragung komprimieren und so eventuell schneller übertragen als wenn du die Insert Statements überträgst. Das macht aber nur sinn wenn die Daten auch sinnvoll komprimiert werden können bzw. überhaupt etwas zu komprimieren ist. Also wenn du die einen Status von 5 Zeichen übertragen willst ist das etwas oversized.

Ein zweiter Punkt, bei direktem Zugriff, wäre das du auf jedem Client dann auch für den DB Zugriff die entsprechenden Client Bibliotheken brauchst. Eventuell je nach DB System fallen auch Lizenzkosten je Client an was die Lösung beeinflussen kann.

[chris-2012]

Ist es ein Datenbankserver oder sind es Datenbank-Dateien? MDB und DBF kann so langsam sein, dass es praktisch unbrauchbar wird, gerade über VPN / UMTS.

[SilentDemise]

von direktem Datenbankzugriff würde ich abraten. Man sollte einen Webservice / Service davor setzen, der die Kommunikation mit dem Client übernimmt und die Daten validiert. Dieser Service schreibt die Daten dann in die Datenbank.

[flashpixx]

Man sollte einen Webservice / Service davor setzen, der die Kommunikation mit dem Client übernimmt und die Daten validiert. Dieser Service schreibt die Daten dann in die Datenbank.

Wofür braucht man einen Webservice um die Daten zu validieren? Man kann mit Hilfe von Constraints, Trigger und Stored Procedures direkt auf der Datenbank dies machen. Ein Webservice ist durchaus ein Angriffspunkt, wenn er nicht entsprechend für die Datenmenge konzipiert ist.

[dr.dimitri]

Wofür braucht man einen Webservice um die Daten zu validieren? Man kann mit Hilfe von Constraints, Trigger und Stored Procedures direkt auf der Datenbank dies machen. Ein Webservice ist durchaus ein Angriffspunkt, wenn er nicht entsprechend für die Datenmenge konzipiert ist.

Ohne Worte. :old

[dr.dimitri]

Nun zur Frage, ist es sinnvoller eine direkte Verbindung zwischen Client und Datenbank aufzubauen oder einen zwischenschritt in dem nur die reinen Daten in das Firmennetz übertragen werden und nachdem die Daten separat in die Datenbank eingelesen werden. Es geht mir hierbau um die Geschwindigkeit. Der Client soll sich alle 4 Std. mit der Datenbank verbinden und schreiben oder die reinen Daten übertragen.

Das ist ein klassischer Anwendungsfall für eine Middleware sprich Queueing. Deine Anwendung packt die zu übertragenden Informationen, übertragt diese in die Queue und von dort aus werden sie asynchron von einem weiteren Programm abgeholt und abgearbeitet.

Deine dezentrale AW muss nicht warten, bis die Daten wirklich in der DB persistiert sind, sie kann aber davon ausgehen, dass die Pakete übertragen wurden, wenn der Vorgang fehlerfrei abgeschlossen wurde.

Dim

[Schiller256]

Wieso muss man denn bei einer solchen Datenübertragung gleich eine dicke Middelware auffahren? Was ist an meine Queue besser als an einer Dateiübertragung mit anschließender Überprüfung auf Vollständigkeit?

Je mehr Technik man auffährt um so mehr muss auch der Client können. Um mit einer Queue reden zu können brauche ich auch wieder Client Bibliotheken wo ich mich mit Versionen rum schlagen muss.

Auch Webservices sind nicht das Allheilmittel für alle Probleme. Speziell bei der Dateiübertragung fängt man recht schnell an mit Attachments rum zu fummeln das wird nicht von allen Runtimes gleich gut unterstützt. Die Daten als Base64 in den Body zu packen ist was die Performance an geht auch nicht wirklich zu empfehlen schon gar nicht wenn ich die Daten über UMTS übertragen will. Wenn ich ein kleine Leitung habe dann versuche ich die so gut wie möglich zu nutzen und die Daten zu komprimieren.

[dr.dimitri]

Wieso muss man denn bei einer solchen Datenübertragung gleich eine dicke Middelware auffahren?

Es muss ja nicht gleich MQSeries sein. Es gibt auch schlankere Alternativen.

Was ist an meine Queue besser als an einer Dateiübertragung mit anschließender Überprüfung auf Vollständigkeit?

Eine Queue ist asynchron, der Client kann die Daten abschicken und sich dann sicher sein, dass sie am Server angekommen sind. Aber natürlich sind auch andere Methoden möglich. Auf einen Queue kann ich z.B. auch einen lsitener setzen, kann die Reihenfolge der Abarbeitung einstellen etc. das müsste ich ansonsten noch selbst programmieren.

Um mit einer Queue reden zu können brauche ich auch wieder Client Bibliotheken wo ich mich mit Versionen rum schlagen muss.

Das brauchst Du auch, wenn du die Daten per FTP etc. überträgst.

Dim