lign=baseline border=0>
pt; FONT-FAMILY: Verdana">Stored Procedures com Java
Como chamar stored procedures via JDBC
Aprenda a chamar stored procedures de bancos de dados relacionais em JDBC de modo eficiente e independente do banco de dados, conheça seqüências de escape JDBC, e saiba quando usar ou não procedures nas suas aplicações
Todo desenvolvedor Java que atue na área de Sistemas de Informação irá, mais cedo ou mais tarde, se deparar com a necessidade do uso de stored procedures, que são procedimentos armazenados e executados dentro do próprio bancos de dados. Embora haja um debate exaltado na comunidade sobre a relevância deste recurso dentro do Java EE ou com frameworks de persistência de objetos (veja o quadro “Quando usar (ou não) stored procedures com Java”), estamos longe de chegar ao ponto de se considerar as stored procedures como apenas mais uma tecnologia legada.
Há uma variação enorme de sintaxe e recursos disponíveis nas linguagens de programação embutidas em cada banco de dados para a criação de stored procedures, criando dificuldades no porte de aplicações de um banco de dados para outro. Mas felizmente o lado Java é padronizado, graças à API JDBC.
Este artigo foca o lado Java da questão, utilizando exemplos escritos para os dois bancos de dados livres mais populares, o MySQL e o PostgreSQL. Espera-se do leitor um conhecimento de básico para intermediário na instalação e configuração destes bancos. Os fontes para download fornecem scripts SQL prontos para a criação das bases de dados, tabelas e stored procedures de exemplo, que são descritos no quadro “Stored procedures no MySQL e no PostgreSQL”. Também espera-se conhecimento de básico para intermediário da API JDBC, preferencialmente que inclua o uso da interface PreparedStatement. Os dois artigos da série “JDBC de Ponta a Ponta”, publicados nas Edições 41 e 42 tratam deste e de vários outros assuntos relacionados.
Os programas de exemplo Java usam um banco de dados com sumários da venda de produtos por região geográfica, contendo duas tabelas relacionadas: produto e vendas. Os scripts de inicialização do banco de dados, disponíveis para download no site da Java Magazine, já criam estas tabelas, inserem uma massa de dados para testes, e definem as stored procedures que são chamadas pelas aplicações Java.
Se as definições das tabelas são idênticas para os dois bancos, a programação das stored procedures é radicalmente diferente em cada caso, e terá que ser completamente reescrita para rodar os mesmos exemplos em outros bancos como Firebird, Derby ou Oracle. Por isso não iremos entrar em detalhes sobre o código no banco de dados. No entanto, apresentaremos o essencial necessário para o leitor entender o funcionamento das stored procedures e seus parâmetros e o que funciona ou não nos dois BDs de exemplo.
A primeira stored procedure
Um cenário muito comum é chamar uma stored procedure que realiza várias alterações no banco de dados, mas que não retorna nenhuma informação para a aplicação Java. Caso haja algum erro durante a execução da stored procedure, será gerada uma SQLException. Senão considera-se que tudo transcorreu bem.
Para exercitar este cenário, nosso primeiro exemplo chama uma stored procedure, chamada incrementa, que aumenta a quantidade de produtos vendidos dado o produto e a região. A Listagem 1 apresenta o código Java deste exemplo. A listagem apresenta a declaração das procedures no MySQL e PostgreSQL (nessa ordem) de modo a indicar os parâmetros e valores de retorno; o código Java que faz a chamada; e um exemplo de execução da aplicação Java no prompt de comandos do sistema operacional.
Este é um exemplo mínimo do uso de stored procedures em uma aplicação Java: não há retorno de valores nem de registros para a aplicação. O trecho de código em destaque é quem efetivamente faz a chamada à stored procedure.
No exemplo da listagem, foi usado o MySQL, e não colocamos também a versão PostgreSQL para poupar espaço. Como dito na introdução, o uso de stored procedures é um recurso avançado de banco de dados e por isso estamos supondo que o leitor tem um conhecimento um pouco além do básico sobre o banco utilizado, por exemplo como executar comandos SQL interativamente.