PreparedStatement vs. Statement

Question

Is PreparedStatement always better than Statement?
My idea is, PreparedStatement is more efficient when in a loop. (Is this correct?)
But when I read some code, the author always uses PreparedStatement, as if it is preferred no matter what.
Can you let me know if there are differences? Thanks!

Answer 1

While there are certainly times to use Statement, beginners should always start with PreparedStatement, using bind variables.
With Oracle and many other databases, PreparedStatement with bind variables will give you improved perfromance on subsequent execution of the SQL (as long as it's an EXACT string match), even when the following executions are hours, minutes, or even days later, even by a different program. This benefit comes from the database caching the execution plan for the SQL. The execution plan is the result of parsing and evaluating the SQL and is somewhat analogous to compiling a program file. Just as you don't want to compile every time you execute a program, so you also don't want to parse and evaluate every time you submit a SQL statement. Bind variables in PreparedStatements helps you do that.
The variability on how long the database will cache your execution plan comes from the fact that the cache is a fixed size LRU (least recently used) cache. SQL that is used infrequently ages out of the cache and how frequently depends on how much different SQL gets seen by the different database. SQL is "different" if it's not an exact string match (including case and any non-bound data values embedded in it) to something already in the cache. This means that using bind variables with PreparedStatement not only tends to speed up performance for that SQL, it also helps to improve performance on busy databases for everything else by reducing the amount of "different" SQL, thereby increasing the length of time other infrequently used SQL stays in the cache, and thereby improving the cache hit ratio on this LRU cache.
Additionally, PreparedStatement with bind variables helps prevent "SQL injection" attacks, a significant problem of naively programmed web sites. Search the web for detailed explanations, there's plenty of them.
Finally, PreparedStatement with bind variables can make your life easier. Many beginners try to code dynamically built SQL, such as:
String sql = "SELECT * FROM user_data WHERE last_name = '" + lastName + "'";Ignoring SQL injection attacks, that works OK until:
String lastName = "O'Conner";The quote embedded in the name gets matched to first quote after the = in the SQL, and the SQL is broken upon execution. You either need to check all your data to see if it needs to haven embedded quotes escaped, or you use PreparedStatement and bind variables.
There are some SQL statements where, as far as I know, it doesn't matter much, e.g. DDL statements (table creation and the like) and connection altering statements, such as "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYYMMDD HH24:MI'". I'm not sure either is cached, or if caching has any benefit; even if it is and there is, the SQL doesn't vary...
There are some very very rare times when (at least on Oracle), using a bind variable can increase the execution time for some values of the variable; the problem is very rare and is almost always caused by data skew; for most values of that bind variable, the correct thing to do is scan all the data in the table, but for a very few values, the correct thing is to use an index to look up the needed rows. When bind variables are used for that variable, the execution for the "typical" case is picked; if the SQL has the bind variable replaced with an actual value, the optimizer can see that for those few particular values, the index lookup is faster and will use that. This data skew problem commonly comes up with "job status" flags on tables that hold both "in progress" and "completed" jobs. Eventually, the "completed" jobs are 99.99 percent of the data, and find the non-completed ones gets slower than it should be.
Beginners should use PreparedStatements until they understand the exceptions or run into performance problems.