title: Is it better to parameterize your PreparedStatement even if the value is always the same?
body: <p>I always read the blog <a href="http://javarevisited.blogspot.com.br" rel="nofollow">Java Revisited</a> and today I was reading the article <a href="http://javarevisited.blogspot.com.br/2012/03/why-use-preparedstatement-in-java-jdbc.html" rel="nofollow">Why use PreparedStatement in Java JDBC - Example Tutorial</a>. At one point the author writes about parameterization of queries, that is better, safer and more performative use the parameterization provided by the API than to concatenate strings and uses the examples below:</p>
  
  <p>SQL Query 1: PreparedStatement with String concatenation</p>
  
  <pre><code>String loanType = getLoanType();
  PreparedStatement pstmt = conn.prepareStatement("select banks from loan where loan_type=" + loanType);
  </code></pre>
  
  <p>SQL Query 2: Parameterized query using PreparedStatement</p>
  
  <pre><code>PreparedStatement pstmt = conn.prepareStatement("select banks from loan where loan_type=?");
  pstmt.setString(1, loanType);
  </code></pre>
  
  <p>The author explains that by using the parameterization, JDBC driver will check the data and with concatenated String the driver doesn't, it will just run the sent SQL, i.e., if we have that famous <code>OR 1 = 1</code> the query will always return true and there's the classic SQL Injection case.</p>
  
  <p>What was not clear to me is why one is more performative than the other, plus, in case I have a value that is always the same, is this true too?</p>
  
  <pre><code>PreparedStatement pstmt = conn.prepareStatement(select * from users where active = 'S');
  </code></pre>
  
  <p>Or is it more performative use as below:</p>
  
  <pre><code>PreparedStatement pstmt = conn.prepareStatement(select * from users where active = ?);
  pstmt.setString(1, "S");
  </code></pre>
  
  <p>Another question, in this case I think the security issue is the same, because as there is no parameter passing through the user there is no attack, right?</p>