Veja quando o uso de stored procedures não é interessante: http://www.guj.com.br/user.article.get.chain?page=1&article.id=150
hmm… interessante, mas um pouco simplista. Pela chamada, eu achei que o autor fosse explicar o porquê, em termos técnicos, quando usar a SP é ou não é eficiente.
Me interessa particularmente pq esses dias tive que desenvolver algo que copiasse registros de uma base de dados para outra, conforme algumas regras. Como era a toque de caixa, mandaram fazer um script que seria executado de N em N minutos.
A perfomance ficou muito boa, mas a principio tinha pensado em utilizar trigger/procedure para a cópia ser efetuada em “real time”, mas fiquei receoso quanto a queda de perfomance nas operações de inserts e updates na tabela, que não eram poucas. Na dúvida (e na pressa), utilizei o script, mesmo.
Uhm… sugestão: não dava pra colocar os artigos em PDF e em HTML normal, com um fo da vida?
Abrir o reader no Windows demooooooooooooooooooooooora nesta carroça 
fora que acho qeu a possibilidade de duas opções seria bem legal. Tipo o DeveloperWorks, só que com orçamento brasileiro :lol:
[]s
Olá
Vou dar meu pitaco porque fui eu que incentivei o autor para escrever este artigo e porque ele não está aqui neste momento.
A idéia não é afirmar que stored procedures tem pior performance do que código Java. A principal mensagem é que uma determinada SP legada pode ser pior do que código Java escrito em poucos minutos. Principalmente uma SP escrita por um bom programador Java mas sem os conhecimentos de um DBA especializado em performance tunning.
Então talvez seja possível responder a sua indagação sobre quando usar a SP é ou não é eficiente dizendo que é sempre bom manter-se desconfiado e executar um testinho rápido como o autor fez.
[]s
Luca
[quote=“Luca”]…Principalmente uma SP escrita por um bom programador Java mas sem os conhecimentos de um DBA especializado em performance tunning…
[/quote]
Luca, eu acho que um comentário acaba anulando o outro. Realmente, eu concordo que testar as opções disponíveis e verificar qual é mais performática acaba sendo a melhor opção. Acontece que, na falta de um DBA, ou de conhecimentos semelhantes por parte do programador, o teste pode ser feito de forma errada.
OK, minha crítica em relação ao artigo diz respeito a algo que não deveria estar nele, mesmo. Quem sabe algum DBA leitor do fórum pode detalhar melhor a questão de tunning discutida aqui?
Abraço 
Eitcha! :shock: :?
Comentando o tutorial:
Que coisa mais estranha. Realmente, é o jeito mais rapido sim de fazer, mas nao creio que seja o mais apropriado para o caso.
Com certeza, eu faria dessa forma se fosse fazer isso pra poucos registros.
Venho notando que a chamada a procedures é mais lenta que insersoes ou outrs comandos DML ( acho q eh assim que se chama 
).
Eu teria mais duas soluçoes ( vou tentar testar mais tarde ):
- Criar uma tabela temporaria, onde eu incluiria os registros que desejo tratar ( insert direto ). Depois chamaria a procedure para ler essa tabela.
2) Passava a lista como parametro pro Oracle ( tipo VARRAY ). Faria uma unica chamada, e dentro do oracle eu iria ler esse array.
A segunda opção é a mais forte. Creio que ela seja melhor.
flw!
Olá,
Eu olhei o tutorial ia comentar logo pela manhã mas desisiti, eu ia refazer os testes a noite usando um pouco melhor o PL/SQL.
Mas vi os comentarios agora e resolvi dar um pitaco.
Sinceramente, não da pra tirar conclusão nenhuma do teste feito (até da e depois digo qual conclusão tirei ).
Algumas considerações a serem feitas.
Primeiro não foi usado nenhum recurso do PL/SQL a unica coisa que foi feita foi passar o comanda INSERT para dentro do banco e isso não é testar a engine da linguagem. Recursos que falo do tipo BULK COLLECTION, INDEX TABLE, e por ai vai.
Um teste deste nivel deveria ser levado a sério se fosse executado da seguinte maneira:
1° Executa um classe java que faz todo o trabalho na linguagem.
2° Executa um metodo no java que faz chamado a uma procedure que faz todo o processamento no banco.
Considerações finais:
A conclusão que eu disse que dava pra tirar é o seguinte. Se o programador não tem um bom conhecimento da linguagem que o banco trabalha, não sabe como a engine funciona, como ele irá processar o código não faça pelo simples fato de dizer que é o banco que processa. Se o cara é bom em Java faz em Java que com certeza irá ficar melhor do que se estivesse rodando no banco. Agora se é um ponto critico do sistema e qualquer milesimo de segundo faz diferença e você possui um cara experiente em tuning de aplicação no banco faça o teste sim e verifique qual o melhor caminho a seguir.
Ps1.: Qual a maquina e versão do banco que o teste foi feito? E qual maquina rodou o Java?
Ps2.: O tempo de execução da procedure foi em torno 60 minutos, aqui na empresa tenho um rotina que baixa do FTP, le os arquivos e insere no banco mais ou menos 100 mil registro em menos de 30 minutos, isso numa tabela com mais de 50 campos.
Tudo que comentei a cima estou falando isso por mim, pois tenho uma certa experiencia com PL/SQL ( 3 anos ) java (1,5 ano) já trabalhei com Oracle 8, 8i, 9i, 10G.
Bruno,
Esta segunda opção é a maneira correta de executar no banco.
Na procedure tu usa esse array como uma PL/TABLE juntamente com uma BULK COLLECTION onde o banco iria colocar os registros em memória até terminar a PL/TABLE (Array) depois disso o Insert é por lote, não precisando abrir a fechar cursores para cada registro.
Se o teste fosse feito assim teriamos um bom parametro pra analisar
]['s
hauhauahuahauah :lol:
Só num sabia os nomes dos bois ( bulk, table index ) kkkkkkkkkkkk…
Eu ja sofri mto ( e venho sofrendo ) com java e acesso a banco…
Mas é como o fabio disse, num dá pra tirar mts conclusoes sobre qual é mais rápido se nao foi aproveitado 100% dos dois lados…
Olá
Só pela discussão suscitada já fico contente de ter incentivado a escrita deste artigo. Já vimos aqui no GUJ vários posts comentando Stored Procedures mas o que o Fábio e Bruno disseram é muito importante: não basta escrever um código qualquer PL/SQL e imaginar que o fato dele rodar no banco será melhor do que o código Java. É preciso escrever código bom.
[quote=“Fábio”] Um teste deste nivel deveria ser levado a sério se fosse executado da seguinte maneira:
1° Executa um classe java que faz todo o trabalho na linguagem.
2° Executa um metodo no java que faz chamado a uma procedure que faz todo o processamento no banco.[/quote]
Correto, mas a intenção foi usar exatamente a SP que já existia no banco e ela não previa as boas práticas que sugeriram. Tanto o código Java como a Stored Procedure foram enxugadas e reescritas especialmente para o artigo para omitir coisas do cliente e facilitar o entendimento.
Quando me coloco do lado dos que defendem não usar SP para deixar a aplicação independente da base de dados, um dos argumentos é justamente o fato que nem toda empresa dispõe de um DBA que realmente consiga extrair o melhor do PL/SQL. A malfadada Stored Procedure do artigo foi escrita por um ótimo programador Java que deveria já ter feito tudo em Java mesmo sozinho ou com a ajuda de coisas do tipo iBatis ou Hibernate. E o pior é que há muitas outras Stored Procedures como esta que não dão problema porque são usadas para poucos registros.
Ambiente:
Servidor onde está o banco: Pentim III 1.0 GHz, 756Mb RAM, Linux, Oracle 8.1.7
Cliente de aplicação web/struts: Atlhon XP, 1.9 GHz, 512Mb RAM, com Windows 2000, j2sdk 1.4.2_05
[]s
Luca
Sinceramente, o artigo eh bem useless, ao menos que seja o primeiro de uma serie de 100 dizendo “… mas para esse caso, x eh melhor y”, “mas no caso a, utilize d”.
Meus 2 cents que nao acrescentam nada.
Rafael
[quote=“Luca”][quote=“Fábio”] Um teste deste nivel deveria ser levado a sério se fosse executado da seguinte maneira:
1° Executa um classe java que faz todo o trabalho na linguagem.
2° Executa um metodo no java que faz chamado a uma procedure que faz todo o processamento no banco.[/quote]
Correto, mas a intenção foi usar exatamente a SP que já existia no banco e ela não previa as boas práticas que sugeriram. Tanto o código Java como a Stored Procedure foram enxugadas e reescritas especialmente para o artigo para omitir coisas do cliente e facilitar o entendimento.[/quote]
Perfeito, sem sombra de duvidas nessa situação faça com Java direto.
É isso ai Luca e além disso, mesmo a empresa tendo um DBA para o banco é dificil este cara se envolver com desenvolvimento ou parar para fazer o tuning da aplicação. Eu defendeno o uso de SP em alguns casos mas dificilmente faço o uso delas, normalmente coloca tudo no Java, pois sei que a diferença é muito pequena, salvo rarissímas exceções e não vale a pena trancar a aplicação.
]['s
Olá
Rafael, a intenção do artigo foi chamar a atenção sobre as “vantagens” do uso de Stored Procedures (mau) escritas por programadores Java que a meu ver é um fato corriqueiro e fazer isto ilustrando com um exemplo real.
[]s
Luca
pessoal,
achei bem estranho esse artigo/tutorial…
simplesmente ele não explica o pq de nada… somente compara x versus y… e de uma forma bem simplista.
e se a stored procedure do artigo está ruim o codigo java está idem pois a lógica é identica… nao é preciso ser expert em tunning de banco pra saber disso…
alem disso se a execução no sql plus da sp demora 3 minutos e via java 60 está claro que o problema não está na sp…
não sou especialista em java mas certamente tem algo ai que torna a execucao de sp mais lenta que a execucao direta de comandos dml…
seria bom que alguem com maiores conhecimentos tentasse esclarecer o pq disso…
<plagio> Meus 2 cents que nao acrescentam nada. </plagio>
Spiff
[quote=“Spiff”]pessoal,
achei bem estranho esse artigo/tutorial…
simplesmente ele não explica o pq de nada… somente compara x versus y… e de uma forma bem simplista.
e se a stored procedure do artigo está ruim o codigo java está idem pois a lógica é identica… nao é preciso ser expert em tunning de banco pra saber disso…
alem disso se a execução no sql plus da sp demora 3 minutos e via java 60 está claro que o problema não está na sp…
não sou especialista em java mas certamente tem algo ai que torna a execucao de sp mais lenta que a execucao direta de comandos dml…
seria bom que alguem com maiores conhecimentos tentasse esclarecer o pq disso…
<plagio> Meus 2 cents que nao acrescentam nada. </plagio>
Spiff[/quote]
Olá,
Olha só SP no Oracle (acho que em qql banco) é mais lenta que os comandos DML por alguns motivos.
1°) O banco precisa carregar toda o código dela pra memoria. Essa memoria não é a mesma dos comandos DML. Nomalmente a quantidade de memoria pra SP é bem menor que para comandos SQL.
2°) Verificar se ela esta valida.
3°) É preciso liberar espaco nesta memoria para armazenar tua procedure, o banco sempre deixa la disponivel as ultimas SP, Packages e funcitions que foram executadas.
Fora tudo isso, tem o tempo perdido na chamada, trafego de rede, e por ai vai.
Ai o cara pensa, então procedure e uma droga, se for chamado 5 mil vezes como neste teste sim. Agora se tu chamar ela uma unica vez e executar tudo la pode-se ter um resultado melhor que no Java.
Outro problema é o seguinte chamando ela mais de uma vez ela fica na memoria, mas vamos supor que neste tempo alguem usou uma package que precisou ser carregada na memoria. Se ela não cabe toda na memoria disponivel o banco libera espaco. Ai quando tu chamar a procedure novamente la vai o banco ter que carregar, validar denovo, etc.
]['s
Estamos utilizando stored procedures para a camada de negócios. Existem alguns artigos que defendem seu uso nestes casos. Afinal quando eu cheguei já tava tudo desenvolvido em PL SQL, eu não seria nem louco de dizer pra desenvolver tudo de novo… :lol:
Caros, primeiramente, parabéns pelos posts, sou novo aqui no forum e estou muito satisfeito com o conhecimento que me está sendo agragado, pois sou iniciante no Java… Qto as procedures do ORACLE, e essse caso tratado especificamente, tenho a dizer que, realemente da forma que está escrita deverá demorar muito msmo, porém, ao contrário de que muitos pensam, se se simplesmente for utilizado cursor nessa procedure, terá um ganho de desempenho absurdo; façam o teste para tirar a teima msmo, abrindo um cursor e fazendo aquele select, sem nem mesmo usar o bulk…; sei que pode parecer viagem, se formos pensar na teoria dos SGBDS de uma forma geral, entretanto, no oracle, e agora no sql 2005 (os que conheço) essa história muda, uma vez que tratam os cursores de forma especial, diferente do que acontece com os selects executados de forma convencional.
bom, essa é minha opinião. 
[]'s a todos!