In JDBC applications, if you are already a slightly horizontal developer, you should always replace Statement at preparedStatement. That is to say, don't use Statement at any time. Based on the following reason: 1. Readability and Maintenance. Although use preparedStatement instead of Statement to make the code a few lines, this code is much higher than the readability of readability, with a lot of code directly with Statement:
Stmt.executeUpdate ("INSERT INTO TB_NAME (COL1, Col2, Col2, Col4) VALUES ('" var1 ",'" var2 "," var3 ", '" var 4 ")");
PerStmt = Con.PrepareStatement ("INSERT INTO TB_NAME (" COL1, COL2, COL2, COL4) VALUES (?,?,?,?); PerstMt.SetString (1, var1); PerstMt.SetString (2, var2); PerStmt.setstring (3, var3); PerstMt.SetString (4, var 4); perStmt.executeUpdate ();
Don't say more, for the first method. Don't say that other people go to your code, that is, you will read it in a while, you will feel sad.
II. PreparedStatement does the utmost possible to improve performance. Each database will do our utmost to provide maximum performance optimization for the pre-compiled statement. So the pre-compiled statement is possible to be repeated. So the statement is compiled by the DB compiler. Cached, then the next call is not required to be compiled, as long as the parameter is directly incoming the compiled statement (equivalent to a mandade), it will be executed. This is not to say Only a multi-executed statement in a Connection is caught, but for the entire DB, as long as the pre-compiled statement syntax and cache match. So you can do it again at any time, you can do it again. And Statement In the statement, even the same operation, because the data that matches the entire statement is minimally matched, such as: INSERT INTO TB_NAME (Col1, col2) Values ('11', '22'); INSERT INTO TB_NAME (COL1, COL2) VALUES ('11', '23'); even the same operation but because the data content is different, the entire statement itself does not match, there is no cache meaning. There is no database that has the execution code cache after the normal statement is compiled. This time you have to compile the incoming statement every time you execute.
Of course, it is not, the precompiled statement will be cached. The database itself uses a policy, such as factors such as frequency, etc., to determine when there is no longer cache existing precompiled result. Save more space storage new Precoclation statement.
Third. The most important point is greatly improved.
Even so far, there are still some people who have basically evil SQL syntax. String SQL = "Select * from tb_name where name = '" varname "' and passwd = '" varpasswd "" "; if we Put ['or' 1 '=' 1] as a varpasswd into it. User name is free, see what will become?
Select * from tb_name = 'random' AND passwd = '' or '1' = '1'; because '1' = '1' is affirmative, it can be verified. More and: Take ['; Drop Table Tb_name;] As a varpasswd, then: select * from tb_name = 'random' and passwd = ''; Drop Table TB_NAME; Some databases will not succeed, but there are also many databases to make these statements And if you use the pre-bucket statement. Anything you are incorporated will not have any matching relationship with the original statement. (Prerequisite is to support pre-compilation of the database itself, but there may be no server database does not support compiling. Only a few desktop databases are those who have access to direct files) As long as they use the pre-bucket statement, you don't need to make any additional data on the incoming data. If you use ordinary Statement, you may have to do DROP ,; etc. The judgment and extravagation of the forever.
