prepearedStatment

[netty]

Hallo Zusammen,

würde gerne Eure Meinung zu folgendem hören, d.h. ob dieses vorgehen Geschwindigkeitssteigernd oder nicht ist:

Also innerhalb einer Methode rufe ich eine andere Methode auf die dann das prepearedStatment ausführt und ein ResultSet zurückliefert:

ResultSet auditRecord =db.getAuditRecord(examID, param);

public ResultSet getAuditRecord(String examID, String param)
throws SQLException
{
String sql="Select TimeStamp, UserID, ReasonID, CID From ParametersAudit Where ExamID =? And ParamName=?";
PreparedStatement ps = con.prepareStatement(sql);
ps.setString(1, examID);
ps.setString(2, param);
ResultSet result = ps.executeQuery();
return result;
}

 

[TheSunToucher]

EDIT:
sorry, falch gepostet...

 

[TheSunToucher]

Wenn du das Statement bei jedem Aufruf prepare'st bringt das nix. Stattdessen müßte die Klasse ungefähr so aussehen:

[...]
public class Foo {

	[...]
	private String sql = "Select TimeStamp, UserID, ReasonID, CID From ParametersAudit Where ExamID =? And ParamName=?";
	private PreparedStatement ps = con.prepareStatement(sql);
	
	public ResultSet getAuditRecord(String examID, String param) throws SQLException {
		ps.setString(1, examID);
		ps.setString(2, param);
		return ps.executeQuery();
	}
[...]

 

[Bleiglanz]

so nicht richtig, aber erstmal was anderes

gib ein ResultSet nicht in einer public Methode als Ergebnis zurück, das ist bäh, lass das resultset im scope des statements (wer soll wann close(); aufrufen???)

ob ein preparedStatement bei mehrfachem Aufruf was bringt, hängt eigentlich nur vom JDBC Treiber und der Datenbank ab

bei mysql ists wohl so (oder war so?) dass immer jedesmal neu der komplette sql-befehl übertragen wird

beim weblogic applicationserver ist ein connection-pool dabei, der preparedStatements über verschiedene Connections hinweg wiederverwenden kann

usw. usw.

man sollte sie aber trotzdem IMMER verwenden, allein schon wegen des automatischen Quotings der Parameter...

 

[netty]

Nun, da ich in verschiedenen Klassen sehr viel Abfragen brauche und nicht jedesmal eine komplette Verbindung usw. aufbauen möchte.Daher habe ich hierfür eine eigene Database Klasse gemacht. Ich übergebe der Methode nur ein Abfrage und erhalte dann ein ResultSet zurück und schließe dies innerhalb meines Programms.
Des weiteren verwende ich MySQL 4.0.24. Laut einem Artikel ist die Version MySQL 4.1 erst in der Lage server-seitig prepared Statments auszuführen. Ältere Versionen nur Client-seitig, was zu keiner Geschwindigkeitssteigerung führt. Store procedures sind zum Beispiel auch erst ab der Version 5.0 möglich.

 

[Bleiglanz]

Laut einem Artikel ist die Version MySQL 4.1 erst in der Lage server-seitig prepared Statments

pff, hängt aber auch vom JDBC Treiber ab!

verwechlse das mal nicht mit dem Query Cache, der einfach FESTE Sql-String wiederverwertet...

 

[Guest]

was verstehst Du unter fest - den eine parametrisierte Abfrage ist ja nicht fest oder ab wann wird eine Abfrage fest ???
Wie kann denn ein JDBC-Treiber dies beeinflussen?

 

[Bleiglanz]

fest heisst: keine parameter, kein ? drin

z.B. ist "SELECT a FROM b" ein statischer String, den du genausogut ohne preparedStatement abschicken kannst

(der Query Cache von mysql merkt sich einfach diesen festen String, und wenn sich an den daten nichts ändernt, kann das nächste mal, wenn GENAU dieser String kommt, der Cache verwendet werden)

eigentlich sollte ein prepared Statement für

"SELECT a FROM b WHERE c=?"

erst mal an den DB Server übertragen werden, dieser macht einen execution plan (mit dem offen gelassenen Parameter) und du kansst dann diese mehrfach (mit verschiedenen Parametern!) aufrufen und bist schneller als jedes mal einen "eingesetzen" String zu schicken

ob und welche DBs das machen (und wie gut) ist eine ganz andere frage...

 

[TheSunToucher]

Auf MySQL 4 und höher bringen die PreparedStatements auf jedenfall was, da sprech ich aus Erfahrung. Außerdem sind PreparedStatements wie Bleiglanz schon richtig gesagt hat typsicher und das ist nicht nur komfortabler sondern spart die Konvertierungszeiten.