A JDBC driver is the interface between your program and the database. You use JDBC calls (using the classes and interfaces in the package java.sql) and the driver converts this to calls specific for the brand and type of database that you're using. The good thing about this is that if you use a different database, you only have to switch the driver, and you don't need to rewrite your own program.
An SQL statement is just a text string. Before the database can execute the SQL statement, it has to parse and interpret the text string. If you are going to execute the same statement multiple times (maybe even thousands of times), it is very inefficient if the database has to parse the same SQL string every time you execute it.
So you can use a PreparedStatement. With this, the database only needs to parse and interpret the SQL string once, and then you can re-use the statement with different data values as many times as you like - without the database needing to parse the whole SQL statement again and again.
> > A PreparedStatement parses and compiles a SQL
> > statement once, no matter how many times you reuse
> > it.....Wat this means?
> >
> > Compilation is done by whom?
>
> The database
Ummmm not always.
The database and/or the driver. Not your code anyway.
> to know the internal detail...
No. There is no need for you to know this. Just concentrate on writing proper JDBC code.
The statement "I want to know the internal details" is simply not acceptable. It doesn't matter and if you feel it does then you are doing something wrong. Further there are several open source drivers for major databases so if you are just curious you can look at them.
They both pass statements to the database for execution.
When the database executes a statement, it has to do two things:
1 Decide how it is going to execute the statement. For example it might use an index to get hold of the data.
2 Everything else, including retrieving the data.
If you use a statement, it does both stages every time.
If you use a prepared statement, it does stage 1 only once, then stage 2 every time it is executed.
In general, I don't personally use preparedstatements unless I know the statement is going to be executed several times within the same connection with different parameters.
BTW. I thought some of the other responses you had were ignorant and unhelpful.
> They both pass statements to the database for
> execution.
>
> When the database executes a statement, it has to do
> two things:
>
> 1 Decide how it is going to execute the statement.
> For example it might use an index to get hold of the
> data.
> 2 Everything else, including retrieving the data.
>
> If you use a statement, it does both stages every
> time.
>
Not always true.
> If you use a prepared statement, it does stage 1 only
> once, then stage 2 every time it is executed.
>
Not always true.
> In general, I don't personally use preparedstatements
> unless I know the statement is going to be executed
> several times within the same connection with
> different parameters.
Terrible advice and judgement.
>
> BTW. I thought some of the other responses you had
> were ignorant and unhelpful.
Yes. Your post is extremely ignorant.
The bottom line is that one does not choose to use PreparedStatements for performance reasons. They may or may not have performance benefits under variable conditions but it totally and completely irrelevent.
One chooses to use PreparedStatements for two reasons:
Abstracting Formatting of Data Values
PreparedStatements allow you to bind VARCHAR (and other text values), date values and other assorted values to queries WITHOUT having to do specific formatting to the specific SQL dialect used by the database.
This is enormously important. It makes your code portable across not only different DB's (of little importance usually) but different versions of the same DB as well (very important). It also removes formatting errors as a potential source of bugs and errors in your code
Preventing SQL Injection Attacks
PreparedStatements prevent SQL injection attacks through your program. I don;t feel like describing SQL injection in great detail but suffice to say like any security problem it is duly worth considering and preventing.
See http://en.wikipedia.org/wiki/SQL_injection for more on SQL injection.
Summary
The OP was given several helpful replies and then you decided to add your commentary and advice that is miguided and flat-out wrong. So maybe the next time you feel that you need to comment on the value of advice given by others you should consider how much you actually are an expert on the given topic because frankly your advice shows you have really very little understanding of the topic at hand.
But thanks for coming out. Better luck next time.