nicht angemeldet
Moin!
Schade nur, dass der Zaunpfahl invalides (X)HTML erzeugt.
Immer nett, wenn sich der Kritiker durch seine Links selbst widerlegt. Das Ticket einfach mal bis zum Ende lesen... :)
Woher kommt eigentlich die panische Angst vor oder Abneigung gegen Prepared Statements? Nichts könnte schneller oder sauberer sein als Prepared Statements.
Zur Geschwindigkeit hat dedlfix schon argumentiert. Das deutlich aufwendigere Handling kommt hinzu.
Meine Kritik: Prepared Statements helfen ausschließlich beim Einfügen von Daten, lassen einen aber im Stich, wenn es darum geht, Statements anderweitig zu dynamisieren:
- Dynamisch eingefügte Spaltennamen
- Dynamische WHERE-Bedingungen
- Dynamische JOINs.
- ... etc...
Ich muß mich nicht um das Quoting von Parametern kümmern
Was macht ein Prepared Statement eigentlich, wenn man sowas haben will:
SELECT * FROM tab WHERE col LIKE "$var%"
Klar, Escaping allein bringt hier nix, weil die eventuell enthaltenen LIKE-Metazeichen dadurch nicht beeinflusst werden, weshalb man sich leider selbständig eine eigene LIKE-Escape-Funktion bauen muss.
Wie kriegt man das Suffix-Prozentzeichen in die Prepared Statements rein? Und wie kriegt man die in der Variablen eventuell enthaltenen Prozentzeichen dazu, nicht als Such-Metazeichen zu wirken? Ich könnte eine Doku wälzen, weil ich es im Moment nicht weiß - aber wenn du als Experte und Befürworter gerade da bist... :)
ich kann die Statements beliebig oft wiederverwenden (sofern die DB-API das mitmacht), und die DB kann sich großflächig sparen, Strings aus SQL-Statements herauszuparsen.
Das sind alles Vorteile, die im PHP-Umfeld so eher selten zum Tragen kommen.
Und wenn man die DB-Schnittstelle einmal sauber designed hat, funktionieren Prepared Statements auch mit Datenbank-Engines, die das von sich aus gar nicht können - ohne eine Zeile Code ändern zu müssen.
Normale SQL-Statements funktionieren auch einfach so, ohne dass die DB das können muss. Ebenfalls, ohne eine Zeile ändern zu müssen.
- Sven Rautenberg