www.mikrocontroller.net

Forum: PC-Programmierung Connection zu Datenbank


Autor: GGaasstt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo@all...

Ich habe da mal ne Fräge an euch...
Zuerst ein bisschen Hintergrund:
Ich entwickle derweil in VisualBasic.net eine 
Standard-WindowsApplication welche auf einen entfernten oder auch lokal 
betriebenen MySql5 Server zugreift und nachdem ich Commandos 
hingeschickt habe empfange ich auch Daten, oder es werden Daten 
gelöscht, und, und, und...
Das funktioniert auch alles hervorragend. Nur...
Lasse ich die Connection an und für sich zum MySql-Server während der 
Programmbenutzung offen, und schließe sie erst bei Programmende, oder 
öffne und schließe ich sie nach jedem Vorgang (Befehl und Datenempfang 
ggf. LastInsertID)???
Ich habe dazu im Netz eigentlich immer nur gelesen, das man die 
Verbindung so schnell wie möglich wieder schließen sollte, aber warum?
Wenn sich der Datenbank-Server im Inet befindet kann es je nach 
Verbindung ja auch mal 1-2 Sekunden dauern, bis er alleine die 
Verbindung hergestellt hat. Das würde mich als Benutzer des Programms 
empflindlich stören.
Weiss da jemand ein wieso oder warum?

Vielen herzlichen Dank schonmal im Voraus,

GGaasstt

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... Verbindung so schnell wie möglich wieder schließen ...

Ist nur in Verbindung mit Webapplikationen sinnvoll, wo mehr 
Web-Zugriffe gleichzeitig erfolgen als der Mysql-Server an parallelen 
Threads/Connections zulässt.

=> Wenn deine Anwendung nicht für massiven Multiuser-Einsatz gedacht 
ist, Verbindung einfach offenlassen.

Autor: GGaasstt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ungefähr dachte ich mir das nämlich auch.
Also, wenn z.B. ein gut besuchter WebShop am MySQL-Server hängt, 
Verbindung schnellstmöglich trennen.
Isses "nur ein" Daten-Server für Kassensysteme, Vereinsverwaltungen und 
sonstiger kleinkram kann ich die offenlassen...

Vielen Dank nochmal. Wollte mich nur vergewissert wissen,

GGaasstt

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GGaasstt schrieb:
> Also, wenn z.B. ein gut besuchter WebShop am MySQL-Server hängt,
> Verbindung schnellstmöglich trennen.

Auch nicht unbedingt, da können auch Persistent Connections Sinn machen. 
Hängt davon ab, wieviel Zugriffe passieren, und wieviele davon wirklich 
MySQL benötigen usw...

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GGaasstt schrieb:
> Lasse ich die Connection an und für sich zum MySql-Server während der
> Programmbenutzung offen, und schließe sie erst bei Programmende, oder
> öffne und schließe ich sie nach jedem Vorgang (Befehl und Datenempfang
> ggf. LastInsertID)???

Der Aufbau einer Verbindung zu einem MySQL-Server ist bei weitem nicht 
so unaufwändig wie man das gerne glauben möchte. Relativ zu anderen 
Datenbanken ist MySQL da in der Tat recht flott, aber in absoluten 
Zahlen ist der Aufbau einer SQL-Connection immernoch eine 
ressourcenintensive Operation. Man kann diesem Problem etwas 
entgegenwirken, in dem man den MySQL-Server eine Anzahl "vorbereiteter" 
Threads erzeugen lässt ("MySQL Thread Cache"), die bei clientseitigen 
Verbindungswünschen sofort zur Stelle sind. Siehe: 
http://dev.mysql.com/doc/refman/5.1/en/connection-...

Möglicherweise kannst Du auch clientseitig die Verbindung zum Server 
nach einer gewissen Leerlaufzeit einfach zumachen. Wenn die Applikation 
die Datenbank also nicht ständig mit Abfragen befeuert räumt man so 
zumindest teilweise die ganzen serverseitigen Thread-Leichen auf, die 
außer Speicherverbrauch und Zeitverbrauch im Scheduler zu nichts nütze 
sind.

Ohne Deine Applikation und ihr Verhalten näher zu kennen ist es jedoch 
schwierig, Dir gute Ratschläge zu geben. Im Zweifelsfall wäre sowas über 
einen ordentlichen Performance- oder Lasttest zu entscheiden.

> Ich habe dazu im Netz eigentlich immer nur gelesen, das man die
> Verbindung so schnell wie möglich wieder schließen sollte, aber warum?

Hier - 
http://www.mysqlperformanceblog.com/2006/11/12/are... 
- findest Du ein paar Gründe, warum man vor allem Entwicklern von 
(PHP-basierten) Webapplikationen gerne zu sowas rät. Das andere Extrem 
ist nämlich: Manche Entwickler kommen tatsächlich auf die Idee, 
Datenbankverbindungen in Sessions zu speichern, weil sie glauben, sie 
würden Transaktionen benötigen, die sich über mehrere HTTP-Requests 
erstrecken.

Ich persönlich halte das Dogma, Datenbankverbindungen müssten so schnell 
wie möglich geschlossen werden, für Unfug. Bei Web-Appikationen 
beispielsweise, bei denen eine Hand voll Applikationsserver mit einer 
Datenbank interagieren, sind ordentlich dimensionierte Connection Pools 
mit relativ langlebigen Verbindungen zur Datenbank unabdingbar. In 
Deinem Fall kann das anders sein, da Du vermutlich deutlich mehr als nur 
eine Handvoll Applikationsinstanzen am laufen haben wirst.

Überhaupt halte ich Konstrukte, bei denen Clients direkt auf die 
Datenbank zugreifen, für äußerst zweifelhaft. Aus meiner Sicht hat eine 
Lösung mit einem zentralen Applikationsserver nur Vorteile. Sag doch mal 
- was für Vorteile hat Dein Konstrukt gegenüber einer Lösung, die z.B. 
auf einem zentzralen Webservice aufsetzt (was Clientseitig 
implementierte Logik ja in keinster weise ausschließt!)?

> Wenn sich der Datenbank-Server im Inet befindet kann es je nach
> Verbindung ja auch mal 1-2 Sekunden dauern, bis er alleine die
> Verbindung hergestellt hat. Das würde mich als Benutzer des Programms
> empflindlich stören.

Mich auch - und wenn der Aufbau einer Verbindung 1-2 Sekunden dauert 
dann möchte ich ja garnicht wissen, welche hohen Latenzzeiten beim 
Ausführen von Datenbankabfragen anfallen :-/

Stephan

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan M. schrieb:
> Überhaupt halte ich Konstrukte, bei denen Clients direkt auf die
> Datenbank zugreifen, für äußerst zweifelhaft. Aus meiner Sicht hat eine
> Lösung mit einem zentralen Applikationsserver nur Vorteile.

Die Webanwendung kann man doch als Applikationsserver verstehen? 
Vielleicht bei PHP noch nicht aber spätestens bei einer ASP/JSP sind das 
richtige anwendungen die nur im Kontext eines Webserver laufen. Warum 
sollte man dann noch einen Applikationsserver zwischenschalten?

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Die Webanwendung kann man doch als Applikationsserver verstehen?

Jein. Eine Webanwendung ist i.A. eine Kombination aus einem 
Applikationsserver mit serverseitiger Logik und Clients (Browser) mit 
clientseitiger Logik (JavaScript).

> Vielleicht bei PHP noch nicht aber spätestens bei einer ASP/JSP sind das
> richtige anwendungen die nur im Kontext eines Webserver laufen. Warum
> sollte man dann noch einen Applikationsserver zwischenschalten?

Soll und muss man nicht. Der Fragesteller hat eine Applikation, die auf 
den Client-Rechnern läuft (er schrieb: "Ich entwickle derweil in 
VisualBasic.net eine Standard-WindowsApplication welche auf einen 
entfernten oder auch lokal
betriebenen MySql5 Server zugreift").

Was er also macht, ist:
Clientprogramm (auf Clientrechner) -> <WAN> -> Datenbankserver.

Was ich für eine sinnvolle Lösung halte, ist:
Clientprogramm (auf Clientrechner) -> <WAN> -> Applikationsserver -> 
Datenbank

Stephan

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stephan M.

stimm in ging ja um eine richtige Anwendung.

Aber da kann man auch ein teil der Logig in die DB verlagern. Wenn man 
z.b. nicht direkt auf die Tabellen zugreift sonder alles über 
Datenbank-Prozedure abwickelt.
Die meiste Programm (und zwar nicht nur kleine Tools) greifen dirket 
ohne ApplicationServer auf die Datenbank zu.
(Navision, Datev usw )

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Die meiste Programm (und zwar nicht nur kleine Tools) greifen dirket
> ohne ApplicationServer auf die Datenbank zu.
> (Navision, Datev usw )

Klar, kann man alles machen und funktionieren tuts ja meistens auch ohne 
Probleme. Ich persönlich halte halt nichts, wirklich garnichts von 
solchen "Lösungen".

Der Fragesteller hat ja auch geschrieben:

> Wenn sich der Datenbank-Server im Inet befindet

Spätestens da fängts bei direktem Datenbankzugriff an, interessant zu 
werden. Auch wenn Über die Anwenderzielgruppe nichts bekannt ist möchte 
ich doch mal mutmassen, dass irgendwann einer daherkommt, der hinter 
einer Firewall sitzt. Eine Three-Tier-Lösung mit AS und Kommunikation 
auf HTTP-Basis hat (nicht nur) an dieser Stelle entscheidende Vorteile, 
ist aber andererseits i.A. auch nicht so schnell entwickelt.

Stephan

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan M. schrieb:
> Klar, kann man alles machen und funktionieren tuts ja meistens auch ohne
> Probleme. Ich persönlich halte halt nichts, wirklich garnichts von
> solchen "Lösungen".

wenn man immer sehr viele Daten verarbeiten muss ist das aber wesentlich 
effizenter. Es macht kein Sinn von der Datenbank erst ein paar tausend 
datensätze abzurufen sie im Server miteinander zu verrechnen und dann 
daraus ein paar zeilen ergebniss zu ermitteln. Dann sollte man das ganze 
schon in der Datenbank machen. Aber meist geht es mit "normalen" SQL 
Abfragen aber nicht. Da macht es sich sehr gut mit Gespeicherten 
Prozeduren und temp Tabelle zu arbeiten. Und damit ist ein Teil der 
Logik schon on der DB.

Autor: Stephan M. (stephanm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> wenn man immer sehr viele Daten verarbeiten muss ist das aber wesentlich
> effizenter. Es macht kein Sinn von der Datenbank erst ein paar tausend
> datensätze abzurufen sie im Server miteinander zu verrechnen und dann
> daraus ein paar zeilen ergebniss zu ermitteln.

Das ist ja auch nicht der Sinn eines AS.

> Aber meist geht es mit "normalen" SQL
> Abfragen aber nicht. Da macht es sich sehr gut mit Gespeicherten
> Prozeduren und temp Tabelle zu arbeiten. Und damit ist ein Teil der
> Logik schon on der DB.

Schon klar - eine moderne DB kann deutlich mehr als nur Antworten auf 
Fragen wie "Welcher Premium-Kunde hat heute Geburtstag?" liefern. AS und 
datenbankseitige Logik (Stored Procedures) ergänzen sich ja oft.

Egal ob man jetzt einen Client mit direktem Datenbankzugriff hat oder 
eine Dreischichtenlösung mit Client, AS und DB - irgendwo muss die 
Programmlogik ja nun hin. Meine Argumente für den Einsatz eines AS sind 
die zusätzlichen Freiheitsgrade, die man mit einem solchen Aufbau 
erkauft, denn man kann z.B. zwischen zentraler und dezentraler Logik 
unterscheiden (und die zentrale Logik dann weiter in AS-seitige und 
DB-seitige Logik aufteilen).

Andererseits gibts ja für alles einen Markt, und ich will nicht 
abstreiten, dass ein Client mit direktem Datenbankzugriff durchaus eine 
erfolgreiche und auch effizient zu entwickelnde Lösung darstellen kann. 
Nur halte ich persönlich wenig von solchen Lösungen.

Liebe Grüße,

Stephan

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.