Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Artigo Java Magazine 26 - Persistência Turbinada II
Artigo publicado pela Java Magazine edição 26.
Persistência Turbinada II
O lado Negro da força JDBC
Explorando as técnicas de mais baixo nível da JDBC – para desenvolvedores dispostos a ganhar desempenho a (quase) qualquer preço.
Na edição anterior, apresentamos as técnicas de programação JDBC, estendendo o padrão de projeto DAO de forma a obter os mesmos benefícios de desempenho de ferramentas O/R – mas mantendo as vantagens de um estilo de programação de “baixo nível”, acessando o bando de dados diretamente.
Este artigo dá seqüência a nossa série sobre JDBC e persistência em geral, com uma variedade de técnicas e dicas mais curtas que não renderiam sozinhas um artigo inteiro. Um ponto em comum dessas dicas é que vamos explorar “truques sujos” como extensões de JDBC e de SQL, que muitas vezes são inevitáveis em nome do desempenho máximo.
Uma observação; muitas dicas deste artigo não são garantidamente independentes de banco de dados. Minha maior experiência é com o Oracle, mais, em muitos casos, diversos bancos suportam as mesmas técnicas apenas com diferenças nos detalhes (como sintaxes SQL diferentes).
Neste artigo, usamos “banco de dados” (ou “BD” ou “banco”) como termo mais simples para Sistema de Gerenciamento de Banco de Dados (SGBD).
Statements ou PreparedStatments?
É comum a dúvida de que tipo de statement JDBC utilizar: o simples Statement ou sua extensão, o PreparedStatement. Revisando, o PreparedStatement estende Statement de forma a resolver três problemas.
- Simplifica a representação dos parâmetros: não é necessário envolver strings com ‘’ (aspas simples) nem converter datas na sintaxe aceita pelo banco de dados, não é preciso converter booleanos para ‘Y’/‘N’ ou 1/0, e assim por diante.
- Aumenta o desempenho: a execução é mais eficiente porque o driver e/ ou banco de dados processam o texto SQL uma só vez, fazendo um cache da sua representação compilada. Além disso, quando uma consulta é executada, antes de ler os dados do resultado o driver também precisa receber o banco de dados os metadados sobre o resultset (nome, tipo e outras informações sobre cada coluna do cursor de resultados1). Com PreparedStatement, esses metadados só são transferidos na primeira execução; depois também ficam num cache do driver.
Suporta updates em batch2: o PreparedStatement permite executar updates repetitivos, que variam somente pelos parâmetros, com os métodos addBatch() e executeBatch(). (Note que estamos usando o termo “update” em minúsculas para significar qualquer alteração, seja via INSERT, UPDATE ou DELETE, no banco.)
Num capitulo disponível online do livro “Java Programming with Oracle JDBC”,
(oreilly. com/catalog /jorajdbc/chapter/ch 19.html), o autor Donald Bales apresenta um
benchmark comparando ambos os tipos de statements. Ele mostra que Statement é mais
rápido para um número pequeno de execuções de um INSERT (entre ~60 e ~120, variando conforme o driver). Para quantidades maiores de operações, PreparedStatement é até duas vezes mais rápido. Bales adverte contra o uso de PreparedStatement para um número pequeno de operações, mas eu discordo, pois os caches do banco de dados e do driver são de longo prazo: mesmo que você não execute um determinado INSERT cem vezes num loop, certamente irá executá-lo muito mais vezes ao longo de horas ou dias3.Prefiro usar PreparedStatement por default, sempre que não houver evidência de não ser a melhor opção - inclusive em casos onde a funcionalidade de Statement seja suficiente. Esta recomendação é especialmente
forte para bancos de dados de maior porte, que possuem otimizadores de consultas
mais poderosos. Nestes casos o custo de compilação das consultas é maior, pois envolve a análise de estatísticas das tabelas, geração de planos de execução complexos, paralelização de consultas etc.
A documentação da JDBC recomenda o uso de Statement "
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
0 COMENTÁRIO
Space do autor
0
0
