prinzli

Hallo zusammen

Ich habe eine simple Frage:

Wie wichtig ist es, nach dem "Datenbankverkehr" die Datenbank wieder zu schliessen?
Wenn sie nicht geschlossen wird, was könnte das für Auswirkungen haben? Oder hat es überhaupt?

Vielen Dank

Gruss Prinzli

Mister Ad

Flor1an

Es ist überhaupt nicht wichtig. Sobald dein Skript fertig ist wird die Verbindung automatisch beendet. Das einzigste wäre wenn dein Skript, nachdem es alle Querys gesendet hat, noch seeehr viel arbeit zutun hat, dann könntest du mysql_close() verwenden da die Verbindung ja nicht noch so lange offen sein muss bis der Rest vom Skript abgearbeitet wurde.

Aber im Normalfall brauchst die Verbindung nicht explizit zu beenden. Kannst du allerdings trotzdem wenns dir gefällt

Übrigens wenn du deine Verbindung mit mysql_pconnect() öffnest schließt mysql_closer() diese Verbindung nicht!

prinzli

Vielen Dank @RaZoR

Dann werde ich es lassen.

Danke Deiner Antwort.

Gruss Prinzli

Curanai

Ich arbeite über mehrere Datenbanken mit unterschiedlichen Passwörtern und Benutzernamen ... damit da nix schief geht, mache ich immer lieber "zu"!! Weiterhin verschickt mir meine Klasse einen Errorreport, sofern innerhalb des Scripts auf der mir zur Laufzeit unbekannten DB was Unerwünschtes passiert - bequemerweise von mir zum DB-Schließen eingerichtet (inkl. Connect-Zeiten sabbel blubb blah).

Aber: Nur eine DB, nix kompliziertes ... da ist mysql_close(); wirklich optional - für die "schöne" Programmierung würde ich es aber dennoch nehmen. ^^

__________________
Manche Menschen sind wie Schnitzel - nicht zäh, aber beidseitig bekloppt!

Flor1an

Auch bei mehreren Verbindung ist mysql_close() nicht nötig. Du verwendest hoffentlich für jede Verbindung eine eigene Verbindungskennung. Und auch für jeden Query!

Damit ist es überhaupt kein Problem mehrere Verbindungen ohne mysql_close() zu verwenden.

Und was steht in deinem Errorreport? Was kann den auf einer DB unerwünschtes passieren??

__________________
▇█▓▒░◕‿‿◕░▒▓█▇

Curanai

@ Razor: Mein Projekt kommt derzeit auf satte 17 Datenbanken, die ich - in ferner Zukunft als Plan - weiter aufbohren werde und die dann eigene Maschinen bekommen (zumindest 12 davon), was dann als eine Art Cluster laufen wird. Zukunftsmusik, aber bereits in der Aufbauphase berücksichtigt ...

JA, jeder Query hat eine eigene Kennung in Form eines Arrays mit den Connectdaten an die richtige DB ... und die Session des eingeloggten Users regelt den Ort, wo es hingehen muß (ohne die Daten selbst in der Session zu haben).

Weiterhin wird jeder DB-Connect, Query etc. über eine Klasse realisiert ... und vorab immer auf eine bestehende Verbindung geprüft (wenn ja, dann erstmal zu!) ...

Zum Errorreport: Der schickt mir das Query, was verweigert wurde (egal welcher Art), in vollem Umfang ... die Seite, die das Query abgeschickt hat unter Angabe der Zeilennummer ...

"Unerwünscht" wäre z. B., dass ein Insert-Befehl nicht geklappt hat - z. B. bei einer Registrierung. Der User bekommt dann nicht den "fatal error", sondern den Hinweis, dass ein Fehler aufgetreten ist, der Betreiber informiert wurde und ich kann innerhalb weniger Minuten Abhilfe schaffen. Da ich den Query vom Nutzer zur Regge habe, kann ich den - evtl. - korrigieren und einpflegen. Info an Nutzer, dass es geht und ich kann auf dem Wege Schwachstellen ermitteln, an die man vielleicht im Vorfeld nicht gedacht hat (hier aber eher jetzt Verständnisschwierigkeiten).

Ein Beispiel zum Thema "unerwünscht": Ich hatte mal mit einem timestamp() als Erkennung gearbeitet - das ging monatelang gut, bis dann die "logische Millisekunde" kam und zwei Datensätze die gleiche Zeit bekamen ... *gnarf* ... das kann jetzt - dank des Forums hier - nicht mehr passieren (auch die DB-Struktur ist vor Monaten geändert worden) ... aber für solche Dinge habe ich eben meinen Errorreport. Auch die Cronjobs nutzen die Klasse nun ... und wenn hier ein Run nicht läuft (weil z. B. in der Nacht zuvor ein Flag nicht/falsch gesetzt wurde), so muß ich nicht in die Log-Files eiern ... kommt alles per Email und direkt nach Auftreten.

Ich rede nicht von ' im Query oder sowas ... ^^ ... darum kümmert sich eine andere Klasse vor der DB!! :P ... mit dem liebevollen Namen "__SQLInjectionParalyzer".

__________________
Manche Menschen sind wie Schnitzel - nicht zäh, aber beidseitig bekloppt!

agrajag

wow...und du bist dir sicher, dass das so Sinn macht? Mir fällt jetzt wirklich absolut kein Szenario ein bei dem es vorteilhaft ist die Inhalte von einem Projekt auf 17 (inhaltlich) getrennte Datenbanken zu verteilen.
Was versprichst du dir davon für Vorteile? Ausfallsicherheit ist es ja schonmal nicht - fällt ein Server aus kommst du nicht mehr an die Daten die auf nur diesem liegen. Und ob das Performance-Gewinne bringt bezweifle ich doch auch stark - im worst-case zu 17 verschiedenen Datenbanken verbinden zu müssen um die Daten für ein Projekt zu bekommen.... Oder habe ich dich falsch verstanden und das ganze läuft schon irgendwie in einem Master/Slave-Verbund oder als NDB-Cluster (kenne mich da absolut nicht aus ).

__________________
Today you...Tomorrow me.

Flor1an

Wenn die Datenbank auf einem Cluster liegen würde bräuchtest du ebenfalls nur eine Verbindungskennung. Wo die Daten genau liegen regelt die SQL Software.

Ich will hier gar nicht gegen mysql_close() sprechen. Ich hab selber am Ende des Skriptes diesen Funktionsaufruf.

Wie genau meinst du dass? Schließt du bei jedem Query deine Verbindung und stellst dann wieder eine neue her? Oder schließt du jedes mal wenn du eine neue Verbindung aufbauen willst erst alle alten?

Da ergibt sich für mich kein Sinn.

Ebenfalls kann ich nicht nachvollziehen wo bei dir jetzt notwendig ist dass du mysql_close() überhaupt einsetzt.

Zum Thema Logfiles. Ich weiß nicht wieso überhaupt ein "falscher" Query bei dir passieren sollte. Bei mir ist es so dass ein Fehler nur DANN kommt wenn, keine Verbindung zur DB existiert ODER ich schlecht programmiert habe und z.B. einen Query vergessen habe zu escapen etc. Daher brauche ich so einen Errorreport nicht wirklich. Während ich entwickle werden mir Querys, die nicht funktionieren, direkt auf der HTML Seite angezeigt, bei Bedarf kann ich auch über Parameter bei dem Queryaufruf den Query als String ausgeben lassen. Daher macht für mich ein Errorreport nur Sinn falls mal deine DB spinnt und es keine Verbindung zu ihr existiert. Aber sonst treten bei mir keine Fehler auf.



Was mich aber viel mehr interessiert, wieso du 17 verschiedene Datenbanken hast.

__________________
▇█▓▒░◕‿‿◕░▒▓█▇

Curanai

Sorry, war ein wenig im Untergrund verschwunden und musste hierzu jetzt erstmal wieder den Thread ausbuddeln ...

Im Moment, da gebe ich euch beiden recht, ist das Modell "17 DB auf einem Server" unsinnig. Es kommen aber immer mehr Datenbanken hinzu, die - exakt! - langfristig zu einem Cluster auf eigenen Maschinen verarbeitet werden sollen; also ausgelagert und als "stand-alone" rennen - unabhängig von den anderen "Problemen" (sofern welche auf anderen Servern auftreten). Somit gibt es später quasi einen Hauptserver, der die reinen DB-Server entsprechend anspricht und die User ihre Infos von dort bekommen ...

Es ist jetzt nicht (!) so, dass jeder User Zugriff auf alle 17 Datenbanken hat - neeee. Das wäre ja ... haha ... naja ... das wäre ja nun wirklich sau-dumm gelöst. Maximal nutzt ein User 2 - 3 Datenbanken davon.

Um mal eben das "ergibt keinen Sinn" aus Erfahrung zu erklären: Ich habe ein projektinternes Forum, wo wirklich nur Leute rein können, die aktiv am Projekt angemeldet sind. Das Forum hat aber z. B. auch eine eigene (!) DB, die auch in die Backup-Routine mit reinläuft. Vor rund einem Jahr ist das Forum komplett zerrissen ... wahrscheinlich aufgrund Einwirkung von außen. Würde dies jetzt z. B. wieder passieren, so habe ich den Ausfall fürs Forum - nicht fürs ganze Projekt. Fällt eine projektbezogene Datenbank aufgrund von irgendwas aus, so fallen nicht alle anderen gleich mit aus - daher habe ich es getrennt!

Es gibt Abfragen, die laufen auch über mehrere Datenbanken - z. B., wieviele Plätze noch frei sind in der Datenbank. Hierzu übergebe ich jetzt nur noch die Kennung (!) an meine Klasse und die macht den Rest - anschließend wird diese Verbindung gleich geschlossen (eine Schleife - der nächste Zugriff geht auf eine andere DB mit anderer Kennung). Jetzt tritt hier meinetwegen ein Fehler auf ... die Datenbank ist nicht erreichbar. Anstatt, dass der User jetzt eine Errormeldung bekommt, bekommt dieser einen Standardtext über einen aufgetretenen Fehler. Im Hintergrund bekomme ich aufgrund dieses Errors sofort eine Mail - mittlerweile sogar noch eine SMS, wenn irgendwas auf dem Live-Server unrund läuft.

Ich fasse mal zusammen:
- 17 DBs, weil später ein Clusternetzwerk kommen soll
- raucht eine Datenbank ab, sind nicht automatisch alle anderen User betroffen
- die Klasse, weil jede DB eine eigene Kennung erfordert aufgrund User/Pw
- die Kennung wird über das Login für den User erstellt - er kann dann nur da hin!
- mysql_close() benutze ich in meiner Klasse, da an dieser Stelle von mir bei Bedarf ein Errorlog per Mail/SMS verschickt wird

*puh* ... gestern hatte ich übrigens eine Demo, wo ein solcher Fehler auftrat. Es fehlte ein FROM in einem Query - albern, jo und durchaus auch ein Flüchtigkeitsfehler meinerseits (Copy/Paste zu weit gezogen). Aber anstatt, dass man als Benutzer nun eine kryptische Fehlermeldung mit mysql_error() etc. bekommt, stand da nur, dass es halt gerade net geht ... die Email war sofort da, es stand inkl. Zeile drin, wo es klemmt, behoben und lief sofort ... der Mensch, der das hier beäugte, war schwer beeindruckt.

@ Razor: Während ich progge, werde mir auch Fehler direkt angezeigt ... aber das soll eben auf der Live-Maschine nicht mehr so sein und ich will mir ersparen, Log-Files vom Server zu lesen.

Mehr Fragen? Mehr Antworten! Können ja sonst auch mal Telefonieren ... no problem!

__________________
Manche Menschen sind wie Schnitzel - nicht zäh, aber beidseitig bekloppt!

Flor1an

Hi, cool dass du einen Weg aus dem Underground gefunden hast und dich nochmal gemeldet hast!

Wenn du eine getrennte Entwicklungs, Test und Produktionsumgebung hast, kannst du sicher sein dass ein Query richtig laufen wird! Sowas wie ein "Flüchtigkeitsfehler" sollte doch wirklich nur dann passieren wenn du direkt in der Produktionsversion arbeitest. Bevor ich mir jetzt eine Methode implementiere um solche Fälle abzufangen, trenne ich doch lieber gleich die Bereiche und teste meine neuen Versionen erstmal bis sie funktionieren. Damit sollten fehlerhafte Querys auf jeden Fall entdeckt werden! Was dann noch an Fehlern übrig bleibt ist sicher nicht in Querys zu suchen und wenn dann sind es logische Fehler wie fehlende Bedinungen oder falsche Verknüpfungen, die aber für die DB trotzdem einen korrekten Query darstellen. Und von deinem System nicht bemerkt werden würden.



Wenn du später wirklich mal ein Clusternetzwerk einführen möchtest, dann hast du mit 17 verschiedenen DBs aber einen Konzeptionsfehler!

Ein Cluster funktioniert so dass du einen Load Balancer hast der die Anfrage an die Datenbank auf die verschiedenen Nodes verteilt. (Gibt auch andere Methoden aber vom Nutzer der DB sieht es nach Außen hin gleich mit meiner beschriebenen Version aus!) Das regelt das Datenbanksystem intern, nach außen hin sieht alles wie ein einziger DB-Server aus! Das bedeutet für dich dass du natürlich auch nur eine einzige Verbindungskennung und damit nur einmal Zugangsdaten brauchst.

Dahinter steckt ja auch der Sinn und Zweck eines Clusters dass er beliebig skalierbar bleibt OHNE dass die Applikation die darauf läuft geändert werden muss. Darum sind Cluster auch ne super interessante Sache!



Was mir jetzt noch einleuchtet ist die Ausfallsicherheit! Klar wenn der eine Server abkackt ist nur ein Teil deiner Applikation davon betroffen.

Auf der anderen Seite, wenn du wirklich einen Cluster hast, dann hast du erst recht kein Problem mehr mit Ausfällen! Dann laufen alle deine Applikationen weiter ohne das auch nur eine Einzige ausfallen würde! Da die Nodes synchronisiert werden läuft deine Applikation einfach auf einem anderen Node weiter, ohne dass der User etwas davon mitbekommt. Der Node kann dann später ausgetauscht werden, Benachrichtigung des Admins kann man bestimmt auch einstellen.
-> Wieder ein spannender Punkt in Sachen Cluster! Und, wie schon gesagt, das alles über eine Verbindungskennung läuft! Die Skalierung, die Ausfälle verschiedener Nodes, das alles organisiert die DB-Software selber ohne dass du dir Sorgen machen musst.

Die Frage ist auch ob die Performance bei verschiedenen Kennungen wirklich besser wird, ich denke einen Großteil der Zeit braucht eine Applikation um eine Verbindung zur Datenbank herzustellen, der Query danach wird wohl nicht so lange dauern.