Eine der automatischen „Goodies“ bei mysql_connect (wen man es denn schon nutzen muss, warum auch immer), ist, dass, wenn man mysql_connect mit den gleichen Informationen bestückt, diese Funktion die gleiche Verbindungsid zurückgibt wie beim ersten mal … es wird also keine zweite Verbindung aufgebaut.

Das Problem ist nun leider, dass der, der die zweite Verbindung öffnen möchte, diese Informationen _ganz genau_ braucht, denn sonst erhält man unter Umständen trotzdem eine zweite Verbindung, obwohl man die vermeindlich gleichen, aber nicht selben Parameter benutzt.

Beispielcode:

$dbserver1 = '127.0.0.1';
$dbserver2 = 'localhost';

$dbuser1 = 'root';
$dbuser2 = 'Root';
$dbpass = '';

$db1 = mysql_connect($dbserver1, $dbuser1, $dbpass);
$db2 = mysql_connect($dbserver2, $dbuser2, $dbpass);
$db3 = mysql_connect($dbserver1, $dbuser2, $dbpass);
$db4 = mysql_connect($dbserver2, $dbuser1, $dbpass);
$db5 = mysql_connect($dbserver1, $dbuser1, $dbpass);

var_dump($db1, $db2, $db3, $db4, $db5);

Ausgabe:

resource(7) of type (mysql link)
resource(9) of type (mysql link)
resource(11) of type (mysql link)
resource(13) of type (mysql link)
resource(7) of type (mysql link)

Hier zeigt sich, dass insg. 4 verschiedene Connection-Ids zurück gegeben wurden, $db5 ist zur Kontrolle und zeigt, dass nur die exakt selben Parameter zum gewünschten Ergebnis kommen, nämlich die selbe ID zu benutzen, die schon bei $db1 erzeugt wurde.
Im Realfall würde dies nun 4 Prozesse bedeuten, von denen 3 überflüssig sind und nur den Server belasten … pro Aufruf im schlimmsten Fall.

Floats, also Fließkommazahlen, in eine DB zu schreiben sollte man können. Dachte ich bis vor kurzem 😉

Und deshalb, vor allem als Hinweis an mich selbst: Falls ein Query mit einem – vorher bereits vom Punkt befreiter, das Komma in Punkt umgewandelten – String plötzlich nicht mehr korrekt ausgeführt wird, dann liegt das höchstwahrscheinlich an zwei Sachen; allein, eine war mir dann neu:

1. Du übergibst deinem Query die Parameter via sprintf (oder äquivalenten davon) und (jetzt kommt das neue)
2. dein Server spricht plötzlich Deutsch!

Um einen fehlerhaften Query aber dauerhaft zu vermeiden, setze ich vor meinen Query nun die Sprache des Systems auf die Sprache der Datenbank und dannach wieder zurück. Den Quellcode habe ich stark vereinfacht mal hier angefügt.

// Wechsel zur internen Sprache der DB, als Beispiel fest im Code
$old = setlocale(LC_NUMERIC, NULL);
setlocale(LC_NUMERIC, 'us_US');

// Query ausführen. Werte im Query werden via sprintf eingegeben
// ...

// Zurück zur normalen Einstellung
setlocale(LC_NUMERIC, $old);

Ich hoffe, ich kann damit mal jemanden aus der Patsche helfen, wahrscheinlich bin ich aber wieder mal selbst mein bester Kunde 😉

Ich stieß kürzlich auf diesen Artikel:
Log Everything All the Time
und fand diesen sehr interessant.

Es geht um’s mitloggen von Informationen und der damit verbundenen verbesserung der Debugfähigkeit von Software für dessen Entwickler. Das ganze klingt für mich sehr interessant, vor allem der Punkt, dass man (theorethisch) jeden Zeitpunkt zu jeder Zeit nachstellen kann – klingt sehr nach ZendServer 😉 – wäre für mich zumindest manchmal sehr wünschenswert.

Allerdings kann ich mich gut vorstellen, da so ein logging sehr an der Performance kratzt, aber der Autor gibt weiter unten im Artikel sehr nützliche Tipps, wie man das maximum herausholen kann, wenn man nur schon beim Design ein paar – wie ich finde fundemantal wichtige – Regeln beachtet, z.B. „Formatiere nichts, bis es nicht gebraucht wird“ oder „Nur ein Tabellenlookup pro Log“.

Von mir aus kommt da noch eins hinzu: „Benutze keine Frameworks!“. Au weia, jetzt hauen mich alle Zend-Freaks. Ich will damit sagen, dass beim Thema ‚logging‘ auch die Zeit eine sehr kritische Rolle spielt – wir reden hier ja nicht über ein oder zweimal loggen pro Aufruf, sondern jeden Request, in jeder Funktion, in jeder Klasse, quasi in jeder Zeile – und da zählt jede Nanosekunde. Frameworks haben diesbezüglich aber einen Nachteil: Sie haben Overhead.

Wie auch immer, ich würde gern eine Klasse für dieses Logging entwickeln und würde mich freuen, von euch Anregungen zu bekommen, was diese Klasse machen soll, wie Sie aufgerufen werden sollte (instanz, static, …) und wie und wo die Daten gespeichert werden sollten (spontan kommt mir da mysql in den Sinn, wegen durchsuchen usw.). Ich denke, wenn wir alle Ideen sammeln, können wir eine gute Logging Klasse entwickeln, die alle diese Informationen in einem guten Zeitrahmen erfasst und speichert. Das auslesen kann ja von mir aus wieder längern dauern, da kommt es nicht so auf die Zeit an.

*hm* Eventuell gibt es ja schon so eine Klasse, irgendwo, allein oder versteckt in einem Framerwork. In dem Fall bitte ich um einen kurzen Hinweis, dann kann ich mir die Arbeit sparen und direkt produktiv loggen.

Was denkt ihr über den Artikel? Was haltet ihr von so einer Klasse?

P.S.: Sorry, die Klasse soll primär für PHP sein, die Ideen natürlich für alle!