Ben Sandee wrote:
> Kevin Steppe wrote:
> [snip]
> Kevin,
>
> I agree it's not worth the effort -- primarily because for my projects
> I don't want log data stored in a database anyway -- and I work at a
> company historically known for it's database software! :-) (Sybase)
>
> I do take issue with two of your statements, #2 and #3 in particular.
>
> #2, I don't see how escaping is still a problem -- with string columns
> you can simply pass any data into the parameter without escaping at
> all. You don't need to know anything about the contents or the target
> database server.
try sending the following into a string column without doing any escaping:
hello "john" I'm Kevin, we're friends "you and I"
such as: insert into testTable (StringCol) values (hello "john" I'm
Kevin, we're friends "you and I")
To make it work you'll need a few backslashes -- plus you'll need quotes
at either end of the value which aren't escaped, note that neither
double nor single quotes will solve the problem in this corner case.
Then write me an algorithm to insert backslashes in the generic case
where some quotes don't need an escape such as:
insert into lt (message) values ('%m')
-- ie, the quotes shouldn't be escaped, but the whole string once
formated will need escapes inside
Then I'll happily put that algorithm to use!
>
> #3, this performance opinion of prepared statements is very
> implementation dependant. I'm not sure what exactly is giving you
> negative feelings towards the PreparedStatement object, but realize
> that the performance levels vary widely by driver -- the
> PreparedStatement implementation often gets the shaft when it comes to
> optimization time, I fear. For the JDBC driver produced by my
> employer, prepared statements and normal statements have effectively
> the same performance level -- it doesn't really matter how you are
> passing the parameters. With our JDBC driver, it isn't actually
> preparing the statement and caching the query plan on the server
> unless you enable a flag in the JDBC driver to explicitly do
> server-side statement preparing. If this is done, performance can
> vary widely depending on whether or not the statements actually get
> re-used or not. Many times it goes down, sometimes, if there is much
> statement reuse it will go up.
>
> Unfortunately the JDBC spec leaves out the possiblity of a
> parameterized "unprepared statement" for those times when I have a
> query that I don't plan on re-using. It really is almost obscene that
> we ever need to resort to generating queries by concatenating strings,
> as advanced as other pieces of the Java API's have become... <shrug> :-)
I completely agree with you here. And b/c most of the implementations
I've used don't give any benefit to PreparedStatements, I shy away --
finding it easier to do string manipulations than keeping track of
variable counts and variable types -- personal preference I suspect.
Additionally I use mySQL a lot which doesn't support
PreparedStatements. And lastly, when I really -do- want the performance
of re-using a statement, I make a stored procedure and call it as a
regular statement.
My point about this is that the configuration and implementation is
easier using string formating than JDBC style binding.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
