Connection zu Datenbank

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

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

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

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-php-persistent-connections-evil/ 
- 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

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

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

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