Diferença entre Statement e PreparedStatement

O motivo mais convincente para escolher entre um e outro que eu conheço é: se a instrução SQL (seja insert, delete, update ou select) é fixa (não muda nunca), usa-se o Statement. Mas se você usar comandos dinâmicos, que se alteram em tempo de execução mediante a passagem de parâmetros, então o ideal é usar PreparedStatement. É possível usar Statement para montar comandos dinâmicos sim, mas você tem que ficar concatenando strings, delimitando valores do tipo caractere com aspa simples… com PreparedStatement fica bem mais fácil e o código fica mais clean.

Alem do que o ADEMILTON falou… a instrução em um PreparedStatement é compilada, e é ideal para ser executado varias vezes consecutivas…

Opa, valeu! Ja entendi como funciona!

Só uma pequena dúvida: o PreparedStatement não funciona com nomes de tabelas né?

por exemplo:

PreparedStatement ps = con.preparedStatement("DROP TABLE ?");

ps.setString(1, "cliente");

ps.executeUpdate();

tive testando e não obtive sucesso...

Kara não tive uma esperiencia boa utilizando STatement
pq quando coloquei meu Sistema em rede Fiko uma caroça
so
muito lento mesmo
ai tive que usar PreparedStatement

Então cara…
sabe o que é?!
o PreparedStatement é tã espertinho, que quando você dá um setString nele, ele já coloca as aspas sabe?
você não precisa se preocupar se tem ’ no teu valor…
então por causa disso acho que você não consegue colocar o nome da tabela… o sql vai pensar que é valor…

alguem por favor me corrija se eu estiver errado, mas acho que é isso mesmo!

um abraço!

Sim o PreparedStatement já sabe se é necessário ou não colocar as aspas nos elementos do comando. Muito bom pra não ficar se perdendo em concatenações de instruções gigantescas.

Eu particularmente gosto de trabalhar com CallableStatement´s!

T+

conta ae iktuz, como que funciona esse negócio? =P
porque acha melhor?

abraço!

CallableStatement é uma estrutura para chamada de procedures e functions da base de dados. Eu gosto de usá-las porque posso colocar grande parte de regras de negócio no banco. Qual a vantagem? Eu trabalho com sistemas críticos de alta disponibilidade, ou seja, não podem parar (pelo menos não deveriam ). Se uma regra muda ou é inserida e tivesse de fazer um refactoring no sistema teria de recompilá-lo e refazer o deploy da aplicação. Colocando no banco fica transparente, ao menos no Oracle e SQLServer. Ex.:

String[] validaLogin(String idLogin, String idSenha, String nmModulo,
			String nrIPValido, String sessionId) throws Exception {
		
    Connection con = null;
    CallableStatement cs = null;

    try {
        con = DBConnection.getInstance().getConnection(this.filePath);
        cs = con.prepareCall("{ CALL MODULO.SP_USER_VALIDATE(?, ?, ?, ?, ?, ?, ?, ?) }");
        cs.setString(1, idLogin);
        cs.setString(2, idSenha);
        cs.setString(3, nmModulo);
        cs.setString(4, nrIPValido);
        cs.setString(5, sessionId);
        cs.registerOutParameter(6, Types.VARCHAR);
        cs.registerOutParameter(7, Types.INTEGER);
        cs.registerOutParameter(8, Types.VARCHAR);
        cs.execute();

        Integer param = (Integer) cs.getObject(7);
        String value = (param != null) ? param.toString() : null;
        return new String[] {cs.getString(6), value, cs.getString(8)};
    } catch (Exception e) {
        //LOG...
    } finally {
	//closeAll...
	}

Se daqui a algum tempo quisermos inserir alguma regra nova no Login, podemos fazer dentro da procedure que ´ra aplicação ficará transparente.

Claro, há seus poréms:

[list]

• chamada de funções e procedures são um pouco menos performáticos
• a aplicação fica amarrada ao tipo do banco (o formato de chamada das functions e procedures são proprietárias)
  [/list]

Ser menos performático não implica em ser lento
Chamadas aos comandos podem ser carregados de fora da aplicação facilmente.

É por isso que gosto de CallableStatements, T+

Só complementando o que já foi falado. O PreparedStatement fornece um excelente ganho de eficiência na execução de instruções que são executadas múltiplas vezes.

Sem falar que utilizar PreparedStatement aumenta o nível de segurança dos SQLs que são executados. Impedindo SQL Injection.