Von Anonymous Coward am Sa, 30. November 2013 um 00:56 #
Prepared statements bringen nicht ansatzweise so viel, wie einem immer glauben gemacht wird. Tatsache ist, dass jede nichttriviale DB-Applikation an irgendeiner Stelle dynamisch generierte Queries braucht, und dann wird die Verwendung von prepared statements sehr unschön, weil man sich fast zwangsläufig irgendwo mit den Indizes oder den Typen vertut.
Prepared statements gehen noch nicht weit genug. Was man eigentlich will, ist eine API, um Queries auf Syntaxbaumebene zusammenstöpseln und parametrisieren zu können, und all das nach Möglichkeit typsicher. Ich persönlich kenne in dieser Kategorie nur die Slick-Bibliothek (Scala). Eventuell geht auch SQLAlchemy in diese Richtung, wobei Typsicherheit in Python natürlich nicht zu machen ist.
Weshalb sollte man Indizes in Prepared Statements brauchen (mit Ausnahem von hidden parameters, etc.)? Auch der Typ ist normalerweise relativ egal wenn es um die Sicherheit geht. Was natürlich nicht impliziert, daß das Statement richtig funktioniert.
Zugegeben die dynamische Zusammensetzung von Queries kann mit Prepared Statements allein wirklich nervig sein.
Die Lösung für das Problem nennt sich JPA und Criteria.
Von Anonymous Coward am Sa, 30. November 2013 um 15:38 #
Weshalb sollte man Indizes in Prepared Statements brauchen
Weil man normalerweise einen Index verwendet, um festzulegen, welcher Platzhalter im prepared statement gesetzt werden soll. Beispielsweise mit java.sql.PreparedStatement.setString(int parameterIndex, String x). Und dabei kann man sich eben leicht vertun.
Die Lösung für das Problem nennt sich JPA und Criteria.
Ja, und JPA ist eben etwas völlig anderes als prepared statements und geht viel mehr in die von mir angedeutete Richtung: eine API, mit der man Queries auf einer strukturellen Ebene zusammenbaut, statt mit Strings herumzufummeln.
Ok, jetzt verstehe ich das mit dem Index. Ich dachte an einen Datenbank Index. Die Nummer des Parameters ist natürlich ein ganz andere Sache. Die Parameter kann man hier wirklich leicht verwechseln.
JPA ist eine weiter Abstraktion, welche Prepared Statements verwendet. Die Criteria "Language" abstrahiert hier nochmals und sollte einem alles bieten um die Query möglichst objektorieniert zu beschreiben.
Leider sind einige wenige komplexe Statements damit noch nicht möglich.
Prepared statements bringen nicht ansatzweise so viel, wie einem immer glauben gemacht wird. Tatsache ist, dass jede nichttriviale DB-Applikation an irgendeiner Stelle dynamisch generierte Queries braucht, und dann wird die Verwendung von prepared statements sehr unschön, weil man sich fast zwangsläufig irgendwo mit den Indizes oder den Typen vertut.
Prepared statements gehen noch nicht weit genug. Was man eigentlich will, ist eine API, um Queries auf Syntaxbaumebene zusammenstöpseln und parametrisieren zu können, und all das nach Möglichkeit typsicher. Ich persönlich kenne in dieser Kategorie nur die Slick-Bibliothek (Scala). Eventuell geht auch SQLAlchemy in diese Richtung, wobei Typsicherheit in Python natürlich nicht zu machen ist.
Weshalb sollte man Indizes in Prepared Statements brauchen (mit Ausnahem von hidden parameters, etc.)? Auch der Typ ist normalerweise relativ egal wenn es um die Sicherheit geht. Was natürlich nicht impliziert, daß das Statement richtig funktioniert.
Zugegeben die dynamische Zusammensetzung von Queries kann mit Prepared Statements allein wirklich nervig sein.
Die Lösung für das Problem nennt sich JPA und Criteria.
Grüße,
unreal
Ok, jetzt verstehe ich das mit dem Index. Ich dachte an einen Datenbank Index. Die Nummer des Parameters ist natürlich ein ganz andere Sache. Die Parameter kann man hier wirklich leicht verwechseln.
JPA ist eine weiter Abstraktion, welche Prepared Statements verwendet. Die Criteria "Language" abstrahiert hier nochmals und sollte einem alles bieten um die Query möglichst objektorieniert zu beschreiben.
Leider sind einige wenige komplexe Statements damit noch nicht möglich.
Grüße,
unreal