Stored Procedure x SQL no Código

Programação Java
#1

Fala pessoal do GUJ,blz ?

Bem,negócio é o seguinte : estou trabalhando com um sistema web(Tomcat+Oracle+Framework proprietário similar ao Struts),em que os SQL’s estão espalhados pelo código fonte java :cry: .Um colega estava alterando um método que,baseado em um select,decide se deve executar outras 3 queries através de JDBC ao oracle.Como as duas outras queries dependem do resultado do primeiro select,lhe sugeri que criasse uma Stored Procedure que fizesse todo o trabalho de recuperação de dados e então seria feito apenas uma query à esta Stored Procedure.Outra pessoa sugeriu que as queries deveriam ficar como estão,ou seja,no código java.

As queries são simples,então,na minha concepção a Stored Procedure seria mais rápida e fácil de manter,pois ao contrário de termos 3 chamadas JDBC,seria apenas uma(com o retorno da procedure).Também acredito que o que o banco pode fazer pela aplicação,que este o faça,agora,que a aplicação não assuma uma responsabilidade que o banco de dados poderia resolver,estou certo ?

O que vocês sugerem ? Existe solução melhor para este cenário ? Qual das abordagens traria um menor overhead ao banco de dados ?

P.S-Poderia ser uma Function,View ou Materialized View também,ao contrário da SP.

Sem mais,agradeço.

Cordialmente,

Júlio César Pescuite

#2

Rapaz, é complicado discorrer sobre isso.
São muitas as vertentes de pensamento dos desenvolvedores quando se fala de iteiração à banco com a camada de aplicação.
Eu não usaria Stored Procedure nesse caso. Aliás, nem gosto de usar SP, preferindo para a maioria dos casos a criação de Views ou de um Select por mais complicado que seja…
Com certeza a SP foi criada porque apresentam vantagens sobre os métodos mais tradicionais, mas não sei precisar ao certo quais seriam essas vantagens…

Já sofri muito por pensar assim nas tentativas de migrações…
A aplicação tem que mandar no banco de dados sim e ser “independente” de recursos e etc, pelo menos na maioria dos casos, excluindo os sistemas críticos, na minha opnião…
O melhor é não caçar chifre na cabeça de égua!
Se dá para fazer pela aplicação com um mínimo considerável de desempenho, que o seja, senão faça pelo banco.

Minha opnião…
Um abraço!

#3

A palavra “overhead” indica que vocês realizaram testes de performance e identificaram que existe um custo alto para este processamento, talvez por ele ser executado muitas vezes ou por realizar um cálculo demorado com o retorno da primeira query. Estou certo?

Se não, 3 queriezinhas no banco não são nada.

#4

Na verdade,a questão é um pouco mais abrangente que o citado,pois foi apenas um exemplo.Peguei este exemplo porque ele me fez lembrar que,embora neste caso seja simples,o sistema que trabalho possui vários cenários semelhantes à esse,ou seja : queries GIGANTES espalhadas em código java,que poderiam se tornar,como o colega Linkel mencionou,uma View por exemplo,ou function de banco de dados.

Também concordo que queries pequenas podem ficar na aplicação mas, refazendo a pergunta,em termos de performance e manutenção da aplicação como um todo : chamadas JDBC são mais lentas do que objetos(functions,views etc) de banco de dados ou não ? Fazer select em uma view por exemplo é mais rapido do que fazer 3 ou 4 selects em várias tabelas ? Este é o ponto.

#5

Se o ponto é “qual é mais rápido”, sem análise alguma de ambiente de deploy, quantidade de usuários e quantidade de requisições, então meu raciocínio me leva rapidamente a Assembly.

Eu insisto: “velocidade” de excecução é um problema em tipos específicos de aplicações. Ao invés de investir tempo com esse tipo de tarefa, sempre prefiro refatorar a aplicação.
No caso de vocês, remover o SQL do “meio do código” e colocá-lo em algum local mais acessível para manutenção seria muito melhor. Vocês ganhariam velocidade real de manutenção.

Só para esclarecer, não sou contra utilizar os recursos do banco de dados. Nâo faria uma query em todos os objetos do banco para apenas retornar uma soma para a tela. Contudo espalhar regra de negócio entre o banco e a aplicação é uma péssima idéia. Impossível de debugar, bastante difícil de manter. E ai se algum dia aquela licensa do Oracle expirar.

#6

certamente ficaria mais rapido isso é indiscutivel e é uma pratica comum quando vc desenvolve em Delphi etc… (como eu desenvolvi a algum tempo atras) mas geralmente em linguagem OO ate mesmo pelo conceito do Java de ser multiplataforma e tal quanto mais regras vc colocar no banco mais vc prende sua aplicação no mesmo sendo que uma futura mudança de banco seria um pouco dolorosa.
Acredito que tudo tem seus pros e contras é apenas uma questão de analisar os fatos.

Minha opinião.

Como é Java faria tudo no java mesmo e deixaria o BD apenas como repositorio de dados agora se fosse algo como Delphi, VB etc… ate pensaria melhor em fazer alguns procedimentos no DB.

blz… flw… :slight_smile:

#7

Se sua aplicação será Oracle e você não vê porque mudar, eu colocaria grande parte da regra de negócios no banco.
E, contrariando muita gente, é sim mais rápido. E se o processamento demandar de vários registros processados, é MUITO mais rápido.

Agora, se você pensa em mudar de banco ou fazer uma aplicação multi-banco de dados, aí a afirmação acima não vai muito bem.

Analisando seu caso: se o sistema tem várias consultas JDBC dentro da sua aplicação, me parece que ela JÁ está acorrentada ao Oracle.
Então, não vejo porque não utilizar os recursos do banco.

#8

Stored Procedure, Views e talz não é particularidade do Oracle, como todos aqui sabem…
A questão muito bem levantada é: o controle da regra de negócio…
Se você sai espalhando SP, Fuctions e talz em pontos específicos da regra do negócio então isso lhe será um problema se um dia seu BD escolhido estiver obsoleto ou muito caro para o fim a que se destina, considerando desde BD’s do mundo OpenSource até o Oracle…
Ainda bem que existe o PostgreSQL! Digo isso por causa desses recursos de banco que vez-por-outras somos tentados a usar, sendo que o PostgreSQL não faz feio perto do Oracle, na minha opinião, principalmente por ser totalmente livre…
O fato de se usar um enginer JDBC de acesso não prediz que sua aplicação JÁ está amarrada a qualquer banco de dados; se um dia precisar mudar é só adicionar o seu Jar correspondente e mudar a String de acesso e de driver, simplesmente;
Por essas e outras eu utilizo o verdadeiro SQL com um mínimo de recursos possíveis vindos do BD dentro do meu código java, encapsulado à minha aplicação… É uma forma de se obter mais controle e facilitar ocorrências de manutenções…
Cada um tem suas experiências…
Um abraço!

#9

[quote=Linkel]Stored Procedure, Views e talz não é particularidade do Oracle, como todos aqui sabem…
A questão muito bem levantada é: o controle da regra de negócio…
Se você sai espalhando SP, Fuctions e talz em pontos específicos da regra do negócio então isso lhe será um problema se um dia seu BD escolhido estiver obsoleto ou muito caro para o fim a que se destina, considerando desde BD’s do mundo OpenSource até o Oracle…
Ainda bem que existe o PostgreSQL! Digo isso por causa desses recursos de banco que vez-por-outras somos tentados a usar, sendo que o PostgreSQL não faz feio perto do Oracle, na minha opinião, principalmente por ser totalmente livre…
O fato de se usar um enginer JDBC de acesso não prediz que sua aplicação JÁ está amarrada a qualquer banco de dados; se um dia precisar mudar é só adicionar o seu Jar correspondente e mudar a String de acesso e de driver, simplesmente;
Por essas e outras eu utilizo o verdadeiro SQL com um mínimo de recursos possíveis vindos do BD dentro do meu código java, encapsulado à minha aplicação… É uma forma de se obter mais controle e facilitar ocorrências de manutenções…
Cada um tem suas experiências…
Um abraço!
[/quote]

Será?

Tente rodar um comando desses no MySql, SqlServer, etc.

select SEQ_QUALQUER.nextval from dual

ou este

select decode( TIPO_MOVIMENTO, ‘E’, 1, -1 ) from CORRECOES

etc.

Existem particularidades do banco. Só o MacGiver consegue programar no JDBC puro numa linguagem que todos os bancos entendem. Quando vc trabalha com milhões de registros, uma consulta com funções analíticas, por exemplo, fazem toda a diferença. Vc pode optar por trazer pronto do banco em segundos ou ficar trazendo tudo pro Java e processando em horas. Pra aplicações pequenas realmente não faz muita diferença.

Outra coisa, vc está falando num projeto SÓ em Java.
Prefiro ter a regra do negócio no banco do que no programa em Java e ficar preso ao Java ou ter que reescreve a regra de negócio na outra linguagem que por ventura eu venha a utilizar (projetos paralelos, troca de tecnologia, etc). Aliás, linguagens de programação evoluem ou ficam obsoletas muito mais rapidamente que os banco de dados, tanto que o tão esperado banco OO até hj não teve a aceitação prevista. Basta vc pegar os posts do Java de 2 anos atrás pra vc ver o tanto de “novidades” que surgiram. Tem hora que até desanima. Nem o Java dentro do Oracle teve (creio que foi um dos maiores fiascos da Oracle). Deixar de ficar preso ao banco pra ficar preso à linguagem pra mim não tem muita diferença, conceitualmente falando.

A idéia não é sair espalhando a regra de negócios em 300 lugares e sim centralizá-la em local só. Que seja no Java ou no Oracle. Só que no Oracle é mais rápido.
Realmente o PostgreSQL não faz feio perante o Oracle. Citei o Oracle pq é o banco que ele utiliza. O fato de ser OpenSource/livre pra mim não faz nenhuma diferença e, como já disse em posts anteriores, apostaria muito mais as fichas no Oracle do que num banco OpenSource por que a lei do capitalismo dá vantagens competitivas.

Particularmente, não gosto muito de transformar “bancos de dados” em “tamboretes de dados”. Usar o Oracle só para guardar informação é um desperdício enorme. Sei que estou um pouco contra a corrente do Hibernate e do SQL ANSI puro, mas, tirando as facilidades que o Hibernate o JPA trazem no início de projeto (que pra mim nem fazem tanto diferença por causa de uma metodologia adotada), não creio que seja melhor perder a velocidade de processamento em troca disto.

Sobre manutenção, existem projetos e projetos. No nosso a manutenção é tranquila porque temos certeza que as coisas estarão apenas em um lugar. Creio que isto não tem muito a ver com a regra estar no Java ou no Oracle e sim em como o projeto foi desenvolvido.

#10

Aí, fera, blz…
Concordo contigo na maioria dos pontos de vista…

A diversidade de opiniões é linda! Viva essa diversidade!!!
Não vou prolongar mais esse tópico, não por mim, porque preciso trabalhar…
Mas quando se discute assuntos como performance de acesso a banco de dados é preciso pensar imparcialmente… Porque, como o amigo marciosantri disse, “existem projetos e projetos”. A gente não pode se esquecer disso.
Porque atrelar minha aplicação ao Oracle com essas parafernálias todas se meus clientes não possuem uma reserva de capital suficiente para investir num banco de dados desse porte?
Da mesma forma, porque não pagar e usar todo o recurso de um banco de dados como o Oracle se meus clientes podem pagar por isso?
Tem que ser colocado na balança…
Mas a idéia mesmo aqui, que foi levantada com o tópico, são os recursos de código SQL em aplicações JAVA… Estamos falando de aplicações JAVA e da iteiração com BD e não o contrário…
Um abraço!

#11

Cara,

Ja tive que corrigir um bug onde o sistema chamava uma SP, esta por sua vez chamava 10 SP.
O problema de se usar SP demais é que tende-se a colocar logica de negocio nas SPs ( tipo select clientes que tem pendencias )

Eu nao gosto.

#12

Coisas que já foram ditas aqui:

Stored Procedure é mais rápida mas atrelada ao Banco de dados;
JDBC é mais lento mas mais “portável”.

Bom, vamos a fatos. Diferentes bancos de dados possuem benchmarks diferentes para diferentes consultas. Por exemplo: ninguém bate o MySQL em consultas simples. Outra coisa, pelos benchmarks que tem sido gerados no Rails, é mais rápido fazer a consulta principal e com base nos resultados dela fazer as consultas complementares uma a uma do que uma consulta com joins (que na maioria das vezes, por não percorrer índices, acaba em demorados table scan).

Ou seja, a conclusão pelos benchmarks deles (que são altamente focados no MySql, mas incluem outros bancos), na maioria das consultas é preferível fazer:

select cod_pessoa, nome from pessoa where nome like 'otavio%'

ler todos os registros e depois fazer:

Do que:

Sei que o exemplo não é perfeito, mas essa foi a conclusão deles… É lógico que se o numero de registros do in for muito grande, dá besteira. Mas a conclusão (que me surpreendeu até) foi essa. Espero ter descrito de forma razoável…

abraços,

otávio

#13

Eu já gosto de Stored Procedures, tenho um caso aqui onde todas as validações e e consistências são feitas no bando de dados mesmo.
Isso melhorou a organização, e separou bem as responsabilidades de cada programador.
A aplicação também tem uma visualização desktop (com GTK) e outra web, que compartilham essas stored procedures.

#14

Acho muito bom o trabalho com SP…
Evita de deixar um excesso de validações desnecessárias no meio do código da linguagem, deixando tudo num único lugar, que é o banco.

Assim, pra cada aplicação escrita, não há necessidade de refazer todas as validações.

É claro que as SP’s devem estar devidamente documentadas, para evitar problemas futuros…

#15

Eu pessoalmente não gosto de sp nos sgbd,

para o administrador de banco de dados, já chega os problemas para se gerenciar IO de disco, incluir indiscriminadamente sp, significa incluir nas dificuldades problemas de processamento.

Acredito que sp, são recomendáveis apenas em casos que reduzam significativamente o tráfego de rede, o que muitas vezes também se obtém com boas queryes.

Outro uso aceitável para sp, são em decorrências de triggers etc.

fw

#16

Nao Utilize SP’s para coisas corriqueiras (select, insert) pq o argumento de “é mais veloz” ja foi discutido.
Utilize SP’s qdo precisar fazer coisas ESPECIFICAS de banco, tipo uma dbms_lob ou utl_file da vida (Oracle).

#17

Eu já vi programadores jogando qualquer insert ou update em SP. Aí tb é forçar a barra.

#18