Fragen zu OOP

[nohfreak]

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

[Kropff]

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

[nohfreak]

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.

Danke dir auf jeden Fall schonma!

[Kropff]

Eine andere Idee war noch irgendwie die Variablen im Query automatisch zu escapen

was hindert dich daran, das in die klasse einzubauen ?

gruß
peter

[nohfreak]

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.

[frodenius]

oder eben

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

[TobiaZ]

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.

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

[Griecherus]

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*

[nohfreak]

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.

[PHP-Desaster]

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

[tontechniker]

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.

[nohfreak]

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

[PHP-Desaster]

Hat jemand zufällig nen Link zu nem Tutorial oder einer ausführlichen Erklärung von PDO ?

Im Manual steht alles, was du brauchst!

[nohfreak]

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.

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.