coyUgl

Hallo, ich hoffe, ich hab meine Frage im richtigen Forum positioniert.

Ich plane gerade ein Persistensframework, dass die Beziehung zwischen PHP-Objekten a la Entity-Relationship-Modell auf Datenbankqueries abbilden soll. Um das ganze effizient zu halten, sollen die generierten Queries natürlich gecacht werden. Soviel zur Vorgeschichte.

Ich sehe da nun zwei Ansätze:

1. Query-Templates generieren: "CREATE `${table}` ....." und die Nicht-Terminale zur Laufzeit mit str_replace() ersetzen.

2. PHP-Code generieren: $query = 'CREATE' . $table . '....' und den Code zur Laufzeit includen oder evaluieren.

Nun endlich meine Frage: Gibts hier Erfahrungswerte, welcher der beiden Ansätze schneller ist?

Vermutlich hängt die Antwort letzten Endes davon ab, wie str_replace() im PHP-Kern implementiert ist: Wird str_replace() auf eine native C-Funktion abgebildet (und ist somit schnell), so ist Ansatz 1 vermutlich die bessere Wahl.
Ist str_replace() allerdings intern irgendwie selbst in PHP implementiert (so wie z.B. viele Matlabfunktionen selbst in Matlab realisiert sind), dann ist Ansatz 2 trotz Parsing, Syntax- und Sematik-Analyse und Bytecodeerzeugung wohl der schnellere Weg.

Na, jetzt hab ich mir hier beim Schreiben schon irgendwie selbst die Antwort gegeben - bleibt zu klären, wie str_replace() implementiert ist. Kann mir das vielleicht jemand beantworten? Ist ja wahrscheinlich nicht nur für mich interessant ^^

Viele Grüße,
coyUgl

Mister Ad

mepeisen

Die Extensions sind eigentlich vollständig nativer C-Code. Die einzelnen Typbehandlungen, die Extensions aufrufen können, beispielsweise für Strings, sind relativ gut optimiert.

Der 2. Ansatz ist in aller Regel schneller. Wieviel schneller kommt stark auf den Fall drauf an. Bei einem einfachen Suchen-Ersetzen ist es immer schneller. str_replace nutzt man normalerweise dann, wenn das Template und die Variableninhalte sehr dynamisch werden, beispielsweise über ein Array definiert sind. Bei aufwändigeren Sachen sind RegExps in aller Regel die schnellste Variante.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

xm22

Wie wäre es mit preparedd statements statt dieser replace-Orgie?

coyUgl

Hallo,

danke für die Antworten. Prepared Statements sind eben erst ab PHP 5.1 möglich, ich würde gerne ien paar Versionen abwärtskompatibel bleiben. Ansonsten wäre das natürlich die Lösung.
Im Prinzp hat sich meine Frage damit geklärt, danke!

mepeisen

Prepared Statements gehen jedoch nur bedingt. IMHO lässt sich der Tabellenname nicht dadurch abbilden. Davon abgesehen aber einen Hinweis:
Abwärtskompatibilität bei neuen Produkten sollte die Ausnahme bleiben. Und wenn sollte sie nur bei "sinnvollen" Versionen eingesetzt werden.
Abwärtskompatibilität zu PHP4 macht exakt 0 Sinn. Und Kompatibilität zu 5.0 würde ich nicht machen wollen. Die aktuellen PHP-Versionsstränge sind 5.2 und mit wesentlich neuen Features die 5.3. Es würde also genügen in meinen Augen, bei einer Neuentwicklung alles ab 5.1 zu überstützen, wenn man die Wahl hat.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

xm22

Ist auch richtig, aber ein Query bezieht sich i. d. R. auch auf eine feste Tabelle...

mepeisen

In obigem Beispiel nicht...

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih