✔ PreparedStatement: welche Möglichkeit bietet Platzhalter ?

S

sportingt

Mitglied
Hallo,

Habe eine Reihe von inserts in eine Datenbank zu machen(Oracle).
Dazu möchte ich gerne PreparedStatements einsetzen.
Die Grundsätzliche vorgehensweise ist mir bewußt und ich habe dies auch schon ein paarmal eingesetzt.

Ich möchte mein Statement relativ dynamisch gestalten.
Hierzu möchte ich gerne wissen welche Möglichkeiten der Platzhalter ? bietet?
Kann man damit nur Werte übergeben oder auch teile des DMLstatements?

z.B.
statt...
"INSERT INTO T_TABLE (COL1,COL2,COL3,COL4) VALUES(?,?,?,?)"
pstmt.setString(1, "WERT1");
pstmt.setString(2, "WERT2");
pstmt.setString(3, "WERT3");
pstmt.setString(4, "WERT4");

...in dieser Weise...
"INSERT INTO T_TABLE ? VALUES ?"
pstmt.setString(1, "(COL1,COL2,COL3,COL4)");
pstmt.setString(2, "(WERT1,WERT2,WERT3,WERT4");

Ist sowas in der Art überhaupt möglich?

mfg

sportingt
 
Nein....sicher nicht...das PreparedStatement ist dafür da, um Eingaben so zu fromatieren, damit es SQL Konform übergeben werden kann.

Zum Beispiel kann man sehr leicht Probleme bekommen, wenn man z.B. bei einem Text Feld ein 'this isn't good' übergeben will, weil er ja nicht weiß wo das Ende ist. Daher bereitet der PreparedStatement es so auf, dass es richtig escaped wird.

Bei einfachen (häufig benutzten) Select Statements kann es sogar schneller sein keine PreparedStatement zu benutzen.

Ansonsten gibt es noch die Datenbankabstraktionsschicht Hibernate, wodurch du tabellen als Klassen handhabst und andere schweinische Dinge machen kannst.

The setter methods (setShort, setString, and so on) for setting IN parameter values must specify types that are compatible with the defined SQL type of the input parameter. For instance, if the IN parameter has SQL type INTEGER, then the method setInt should be used.
Zum Vergrößern anklicken....
 
Zunächst hate Anime-Otaku recht, mit dem Platzhalter "?" kann kein Tabellenname o.ä. angegeben werden.

Nein....sicher nicht...das PreparedStatement ist dafür da, um Eingaben so zu fromatieren, damit es SQL Konform übergeben werden kann.
Zum Vergrößern anklicken....

Aus Entwicklersicht mag das auch stimmen, für die Datenbank bedeutet ein Prepared Statement aber was ganz anderes:

Jedes Statement wird von der Datenbank geparst. Abgesehen von Prüfungen auf Syntax und Berechtigungen des jeweiligen Users muss die Datenbank einen EXECUTION Plan erstellen. Hier sucht die Datenbank z.B. bei einem SELECT die schnellste Methode die Daten zu ermitteln... (nehme ich diesen Index, oder doch ein FULL Table Scan ... etc)
Das ganze ist recht aufwendig und erzeugt einen nicht unerheblichen Overhead.
Bei einem Prepared Statement muss das die Datenbank nur einmal machen und kann bei allen weiteren Statements, bei denen sich ja "nur" die Variablen, niemals aber die Tabellen ändern können, den gleichen EXECUTION Plan verwenden.

Nehme ich keine BIND Variablen ist für Oracle (meistens) jedes Statement unterschiedlich und es muss ein neuer EXECUTION PLAN erzeugt werden:
Dies hier wäre z.B. sehr schlecht:
SQL: 
=> execute SELECT * FROM TABLE WHERE myTEXT = 'string1';
=> execute SELECT * FROM TABLE WHERE myTEXT = 'string2';
Besser:
SQL: 
=> prepare: SELECT * FROM TABLE WHERE myTEXT = ?;
=> add Parameter 'string1'
=> execute
=> add Parameter 'string2'
=> execute

Hier ist eine kleine Demo zur Verwendung von Bind Variablen, zwar in PL/SQL aber in Java sollte es ähnliche Vorteile bringen:

http://www.tutorials.de/forum/relat...1-a.html?highlight=Bind+Variablen#post1322221

Daher kann ich die Aussage
Bei einfachen (häufig benutzten) Select Statements kann es sogar schneller sein keine PreparedStatement zu benutzen.
Zum Vergrößern anklicken....
nicht wirklich nachvollziehen ?
 
Zuletzt bearbeitet von einem Moderator:
Hallo!

Schau mal hier:
http://www.oreilly.com/catalog/jorajdbc/chapter/ch19.html

There's a popular belief that using a PreparedStatement object is faster than using a Statement object. After all, a prepared statement has to verify its metadata against the database only once, while a statement has to do it every time. So how could it be any other way? Well, the truth of the matter is that it takes about 65 iterations of a prepared statement before its total time for execution catches up with a statement. This has performance implications for your application, and exploring these issues is what this section is all about.
When it comes to which SQL statement object performs better under typical use, a Statement or a PreparedStatement, the truth is that the Statement object yields the best performance. When you consider how SQL statements are typically used in an application--1 or 2 here, maybe 10-20 (rarely more) per transaction--you realize that a Statement object will perform them in less time than a PreparedStatement object. In the next two sections, we'll look at this performance issue with respect to both the OCI driver and the Thin driver.
Zum Vergrößern anklicken....

Ansonsten bringt sowas im Prinzip wirklich nur was wenn man eine ganze Latte von Statements absetzt. In diesem Fall bietet sich auch die verwendung von batch Updates an. -> Statement -> addBatch(...) , executeBatch()

http://www.tutorials.de/forum/java/225803-jdbc-mehrere-insert-auf-einmal.html?highlight=addBatch

Gruß Tom
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück