Moin Leute,

ich fange grade mit OOP an und habe mir dazu mal die Tutorials von Kropff zu Gemüte geführt. Nun tauchen dabei doch einige Fragen genereller Art auf, die ich gern beantwortet haben würde.

Ich habe dort gelesen, dass beim Erzeugen von Objekten für diese Arbeitsspeicher reserviert wird. Bei dem Anfängertutorial 3 ( die MySQL-Klasse ) ist dann ein destructor drin, der die Verbindung löscht, weil sonst -> "Trotzdem bleibt der Verweis darauf bestehen. Ein Destruktor ist also eine elegante Möglichkeit, aufzuräumen."

Daraufhin stellte sich mir doch die Frage wie lange ein erzeugtes Objekt Ressourcen frisst, sofern es ohne destructor ist. Wenn ich in einem Script ein Objekt erzeuge, kann ich das dann nur in dem Script verwenden, oder ist das dann wie eine Session auch Super_Global verfügbar ?

Als erste eigenständige Arbeit wollt ich probieren diese MySQL-Klasse zu erweitern, hat da jemand ne Anregung, was man da noch alles reinpacken könnte ? ^^

Greetz,
nohfreak

Wenn ich in einem Script ein Objekt erzeuge, kann ich das dann nur in dem Script verwenden, oder ist das dann wie eine Session auch Super_Global verfügbar ?
ersteres.
Als erste eigenständige Arbeit wollt ich probieren diese MySQL-Klasse zu erweitern, hat da jemand ne Anregung, was man da noch alles reinpacken könnte ?
die mysql-klasse aus dem 3. tutorial ist extrem rudimentär und bezog sich nur auf die __autoload-geschichte. darum kannst du die mit massenhaft zusätzlichen methoden ausstatten. rückgabe der anzahl von treffern (mysql_num_rows), rückgabe der anzahl betroffner datensätze (mysql_affected_rows), usw

gruß
peter

Original geschrieben von Kropff

die mysql-klasse aus dem 3. tutorial ist extrem rudimentär und bezog sich nur auf die __autoload-geschichte. darum kannst du die mit massenhaft zusätzlichen methoden ausstatten. rückgabe der anzahl von treffern (mysql_num_rows), rückgabe der anzahl betroffner datensätze (mysql_affected_rows), usw


Jau, und das find ich grade gut als erstes Projekt. Was rudimentäres weiterentwickeln. Ich mein, so ne MySQL-Klasse kann man ja immer gebrauchen. Gibts zwar bestimmt schon überall zu Hauf, aber ich finds toll sich selber was zu basteln. *gg*

Eine andere Idee war noch irgendwie die Variablen im Query automatisch zu escapen, aber in die Klasse geht ja schon das fertige Query rein, darum braucht man dafür vielleicht eher ne neue.

Aber irgendwie gehts eher ins Offtopic grade. :D

Danke dir auf jeden Fall schonma!

Eine andere Idee war noch irgendwie die Variablen im Query automatisch zu escapen
was hindert dich daran, das in die klasse einzubauen :) ?

gruß
peter

Naja, wenn ich das richtig sehe wird das Query ja schon als String an die Klasse übergeben. d.h. die Variablen sind schon durch ihre Werte ersetzt, sofern Werte im Query vorhanden sind. Danach noch zu escapen wäre nicht gerade sinnvoll.

bzw. keine Ahnung wie ich z.B. aus folgendem auf die Variablen zurückschließen kann:


$query = "SELECT foo FROM bar WHERE johndoe ='".$bla."'";


$bla wird dann doch durch den Wert schon ersetzt odernicht ? Und das escapen müsste ja irgendwie dann schon vorher passieren.

oder eben

$query = "select * from t_one where name = ". mysql_real_escape_string($bla) ." and whatever = 'no'";

bzw. keine Ahnung wie ich z.B. aus folgendem auf die Variablen zurückschließen kann:

PHP:
$query = "SELECT foo FROM bar WHERE johndoe ='".$bla."'"; Wenn das was du schreibst, der Fall wäre, dann wäre es ja kein Problem. Aber deine Klasse, bzw. query() bekommt nur den kompletten String und da ist es unmöglich zu unterscheiden, was echt ist und was escaped werden müsste.

Du musst also zwangsläufig den String außerhalb escapen. Entweder mit den fertigen Funktionen (s.
frodenius) oder aber, was sich bei einer Klasse sicher anbietet: die passende Methode escape() implementieren. Letztendlich tut die aber das selbe wie mysql_real_escap_string() und könnte so aussehen: function escape($string) { return mysql_real_escape_string($string); } Das erspart dir wenigstens Schreibarbeit.

als alternative kannst du dir auch die variablen als extra parameter an die class übergeben. / ähnlich printf() / im query selber machst du halt nur die platzhalter rein und gibst den inhalt separater weiter.

Original geschrieben von Abraxax
als alternative kannst du dir auch die variablen als extra parameter an die class übergeben. / ähnlich printf() / im query selber machst du halt nur die platzhalter rein und gibst den inhalt separater weiter.
Lektüre dazu findest du unter dem Begriff Prepared Statements. *abraxax-ergänz*

Ah, cool, danke, das klingt eigentlich ganz gut mit den prepared Statements. Erscheint mir aber auf den ersten Blick doch recht kompliziert, denke da is es doch einfacher die Variablen vorher einfach zu escapen.

Wobei angeblich die Prepared Statements auch Einiges an Performance einzusparen zu scheinen. Naja, mal sehen.

Danke auf jeden Fall für die zahlreichen Antworten.

Guck dir PDO mal an, vielleicht kannst du von deren Prepared Statements was auf deine Klasse übertragen.

Guck dir PDO mal an, vielleicht kannst du von deren Prepared Statements was auf deine Klasse übertragen. Wenn man die verwendet dann sollte man sie aber auch auf MySQL Ebene verwenden, dort beschleunigen sie nämlich einiges wenn sich eine Query wiederholt.

Wie, auf MySQL-Ebene verwenden ?
Hat jemand zufällig nen Link zu nem Tutorial oder einer ausführlichen Erklärung von PDO ?

Hat jemand zufällig nen Link zu nem Tutorial oder einer ausführlichen Erklärung von PDO ?Im Manual (http://php.net/pdo) steht alles, was du brauchst!

Ah, super, danke dir. Habe mir das nun mal eingehend angeschaut. Die prepared Statements sind an sich ne feine Sache, nur scheint es mir irgendwie nicht den Aufwandt wert, weil ich in einem Script nur relativ selten mehrmals die selbe Query-Struktur brauche. Da jedes Mal ein prepared Statement draus zu machen scheint mir dann doch irgendwie mehr Aufwandt zu sein. Hat natürlich den Vorteil, dass direkt alles escaped wird, aber ich glaube eben selber escapen und dann ein normales Query machen ist von der Tipparbeit her irgendwie weniger als die PrepStatements. Wenn ich alles vorbereiten lasse, und im Endeffekt doch nur einmal im Script nutze, dann verblasst auch der Performance-Vorteil, oder sehe ich das falsch ?

Interessant hingegen finde ich die Persistene Datenbank-Verbindung. Bisher is es bei mir echt so, dass bei jedem neu-aufrufen eines Scriptes ( also quasi jedes mal wenn ein User eine Seite neu läd ) eine Verbindung aufgebaut und gekillt wird. Das werd ich wohl in den Constructor meiner MySQL-Klasse einbauen, das find ich gut. :D

Die Transaktionen klingen eigentlich auch interessant. Wenn man auf mehrere Tabellen zugreifen will muss man nich alle per Hand locken, dass macht PDO dann ja für einen quasi, wenn ich das richtig verstehe.

Original geschrieben von nohfreak
) eine Verbindung aufgebaut und gekillt wird und das ist auch gut so!

stelle dir vor, deine datenbank kann nur 10 gleichzeitige verbindungen ...

stelle dir nun vor ... es sind 5 user auf deiner seite. jeder hat nun ein pconnect() aufgebaut. da du auf einem shared hosting server bist und noch 3+2 andere user auf anderen eine pconnect() verbinden haben könnten ...

ist für den 11 user schluss mit mysql. es kann keine verbindung mehr aufgebaut werden.

also ... bitte UNBEDINGT die verbindung am scriptende manuell stoppen (gerade bei pconnect()) oder das pconnect() nicht verwenden. das ist nichts für leute mit wenig erfahrung.

Wenn ich das Manual von PDO aber richtig verstanden habe hält das die Verbindungen nicht aufrecht, sondern cached die irgendwie. Das soll dann die Datenbank weniger belasten, als ein immer wieder neues Verbingen. Oder hab ich da jez vollkommen Bahnhof verstanden, und die Verbindungen werden da ganz normal offen gelassen ? :>

Da jedes Mal ein prepared Statement draus zu machen scheint mir dann doch irgendwie mehr Aufwandt zu sein. Hat natürlich den Vorteil, dass direkt alles escaped wird, aber ich glaube eben selber escapen und dann ein normales Query machen ist von der Tipparbeit her irgendwie weniger als die PrepStatements. Das stimmt imho nicht so ganz ... zum einen ist meistens sicherer - zum anderen ist es tatsächlich weniger "Tipparbeit": $this -> Database -> query ( 'SELECT * FROM foo WHERE a = ?', array ( $a ) );
// vs.
mysql_query ( 'SELECT * FROM foo WHERE a =' . mysql_real_escape_string ( $a ) );

Ich finde es auch viel übersichtlicher, da du die eigentliche Query und die Daten schön getrennt hast und auf dieses nervige mysql_real_escape_string verzichten kannst.
Außerdem implementiert das PDOStatement Traversable, d.h. du kannst ganz gemütlich in einer foreach-Schleife damit arbeiten!

Original geschrieben von tontechniker
Das stimmt imho nicht so ganz ... zum einen ist meistens sicherer - zum anderen ist es tatsächlich weniger "Tipparbeit": $this -> Database -> query ( 'SELECT * FROM foo WHERE a = ?', array ( $a ) );
// vs.
mysql_query ( 'SELECT * FROM foo WHERE a =' . mysql_real_escape_string ( $a ) );

So funktioniert das aber bei mir nicht. Ich hab folgenden Code:


<?php
$result = $dbh -> query("SELECT * FROM ?", array('accounts')) -> fetchAll(PDO::FETCH_ASSOC);
?>


Und da wirft er "Fatal error: Call to a member function fetchAll() on a non-object in C:\xampp\htdocs\Klassen\test.php on line 5".

Und im Manual steht auch, dass man prepared Statements so benutzt:


<?php

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (?, ?)");
$stmt->bindParam(1, $name);
$stmt->bindParam(2, $value);

// insert one row
$name = 'one';
$value = 1;
$stmt->execute();

?>


Und das wär dann ja wieder bissi mehr zu tippen. Außer man schreibt sich ne Abstraktionsschicht, wo man wirklich nur das Query und die Werte in nem Array hinterherhaut und diesen ganzen Kram von der Abstraktionsschickt machen lässt. Dann wärs wieder cool. :D

Aber nochmal zu der persistenen Verbindung,... Die is also ziemlcih bäh, hab ich das richtig verstanden ? Bzw. könnte da mal jemand ein Beispiel für eine Anwendung geben, wo das Sinn machen würde ? Oder allgemein mal etwas ausführlicher erklären wie das funktioniert. Ich finde die 3 Sätze im Manual dazu nicht sonderlich aussagekräftig muss ich zugeben. :>

Danke übrigends für eure Geduld mit mir.

... wo man wirklich nur das Query und die Werte in nem Array hinterherhaut und diesen ganzen Kram von der Abstraktionsschickt machen lässt. Dann wärs wieder cool. public function query ( $query, $data = array ( ) ) {

if ( empty ( $query ) ) {
throw new ArgumentException ( );
}

$this -> _handle = null;
$this -> _handle = $this -> _pdo -> prepare ( $query );

if ( !$this -> _handle -> execute ( (array) $data ) ) {
if ( $this -> _inTransaction ) {
$this -> rollBack ( );
}

throw new SqlException ( $this -> _handle -> errorInfo ( ) );
}

return true;

} Aber nochmal zu der persistenen Verbindung,... Die is also ziemlcih bäh, hab ich das richtig verstanden ?Richtig.

Ok, mit dem bind*-Aufrufen wirkt es auf den ersten Blick wirklich etwas voller, aber es ist um einiges übersichtlicher im Gegensatz zu lauter mysql_real_escape_string-Aufrufen und Stringverkettungen.
Btw: PDO ist um einiges fixer als ein eigener mysql_*-Wrapper!

Joa, ich habe nun auch beschlossen PDO für meine Datenbankoperationen zu verwenden, ich werd mir wie gesagt nur ne kleine Abstraktionsschicht schreiben, um mir die Tipparbeit mit den binds zu ersparen, oder bei Transaktionen etc.

Danke erstmal für deinen Codeschnippsel Tontechnicker, aber ein paar Fragen hab ich da dochnoch dazu:

Was hat es mit dem _handle, _inTransaction und _pdo auf sich ? Bzw. was genau bedeutet der eine Unterstrich ?

Ich glaube ich mach mal im Brainstorming bei Zeiten nen neuen Thread auf, und hol mir da Tips für die Abstraktionsschicht, bzw. poste da dann mal meine Ergebnisse rein und lass euch euern Senf dazu abgeben. Irgendwie wäre das in diesem THread hier nämlich ein wenig fehl am Platze.

Dennoch wüsste ich gern, was es mit obigen Ausdrücken auf sich hat. :D