Provas. Eu quero provas. ;)[/quote]
voce esqueceu do…
“e não venha com chorumelas!” :lol:[/quote]
Quero ver vc fechar custo, ou mesmo calcular um mrp em qualquer lugar fora do banco que nao leve mais que 2x o tempo do mesmo processo no banco: tenho provas!!! rss…
Acho que tem outra questão também: O Cliente
Aqui pelo menos ele assimiu que não trocaria de banco de dados e que poderiamos usar todas as features do banco de modo que diminuisse o tempo de desenvolvimento
Logo se ele disse isso já era, vamo fazer do jeito que ele quer. Se amanhã ele quer mudar de banco ele vai ter que pagar novamete pelo desenvolvimento do sistema.
O máximo que agente pode argumentar ( e foi feito isso ) é dizer que usando stored procedures e talz, o sistema fica totalmente engessado e que se, se algum dia, eles resolverem mudar de banco de dados, nós teriamos que jogar o sistema no lixo e escrever tudo novamente.
Agora vai discutir isso com cliente que acha m$ é a melhor solução para tudo.
Se você tiver um servidor de aplicações em uma máquina tão boa quanto a do banco de dados, acredito que o processo não seria mais lento do que em stored procedures. 
Concordo que com algumas features que agilizem o processo podemos facilmente aumentar o tempo de desenvolvimento… Mas por que usar as benditas SP do Banco de Dados? Não é mais fácil usar algum Framework específico, já com as classes de acesso aos dados? Mesmo que seja algum framework do Oracle, por exemplo.
E a cruel dúvida: e se vc mudar de linguagem? Eu pergunto: e se você mudar de banco de dados?
Valeus!
Ah, mas pera ai: colocar a regra toda na tua aplicacao e entao disponbilizar pro pessoal “de fora” ( outras tecnologias ) via web services? fala serio neh… que use outro argumento, mas nao nesse…
Soh falta dizer que acessar webservices eh mais rapido que consultar o banco de dados diretamente.
Nessa discussao tem meia-duzia que abominam procedures/banco, e outra meia-duzia que adoram.
Ate parece aquelas discussoes sobre “a minha linguagem eh melhor que a sua”… Ficam tao xiitas sobre uma determinada solucao que fecham os olhos para as outras.
Pega um cara que manja de banco de dados e ele te da milhares de argumentos, e testes, e mais argumentos que deixar no banco e melhor.
Entao pega um carinha que odeia essa idea e ele te dara milhares de argumentos que eh melhor soh trabalhar com objetos.
Entao coloca um carinha que odeia objetos no meio da conversa.
Rafael
Olá
Rafael, você recolocou as coisas no lugar. Não dá para falar desses assuntos como quem fala do seu time preferido. Há que analisar caso a caso. Alías é para isto que estudamos tanto, ou seja, para ser capaz de escolher a melhor solução para cada cliente. Já disse aqui que no dia que as escolhas forem automatizadas meu diretor não precisará mais de mim.
O CV anda esquecendo que as SP foram criadas no tempo em que as conexões custavam bastante e o tráfego na rede invialibizava ficar fazendo todas as consultas pela rede. O uso de SP diminui o tráfego entre o servidor de aplicações e o servidor de banco de dados.
Hoje com o uso de gigabit ou outras ligações de novíssima geração, a questão do tráfego ficou um pouco de lado. Porém muitas empresas ainda exigem que muitas consultas/atualizações permaneçam em SP por pelo menos 3 motivos adicionais:
a) Consultas/atualizações sigilosas que correriam risco ficando no código;
b) Consultas/atualizações otimizadas pelo DBA que quase nunca é o mesmo cara que codifica Java
c) Preservação de regras de negócio independentes da linguagem. Há empresas com várias linguagens acessando a mesma base de dados.
Nós, como supremos especialistas na área, só podemos escolher a melhor solução conhecendo os detalhes do problema do cliente e o quanto ele tem no bolso para gastar.
[]s
Luca
Provas. Eu quero provas. ;)[/quote]
CV,
Provas eu te consigo, mas acho que isso naum leva a nada.
Eu trabalho a 3 anos com Oracle a um com Java e tou longe de saber muito. Mas sei que muitos processos pesados o melhor é estar no banco. Digo o melhor, mas isso nem sempre é feito por diversos motivos. Agora existem processos que não requerem muito e neste caso estar no banco não é o melhor. Ai minha singela opinião coloque fora do banco. Fica melhor para dar manutenção, distribui melhor os recusos, e toda parte de padrões recomendados que temos.
Vou te dar um pequeno exemplo em um projeto que eu desenvolvi a parte de banco.
Um portal de um grande fabricante de motores. Em uma dos front-end o objetivo era mostrar a estrutura de pecas dos motores. Esta estrutura era com SQL Hierarquico. A consulta quando estava no Java levava 30 seg para retornar ao usuário, e por contrato definido com minha empresa tinhamos fazer todas consultas não demorar mais que 5 seg. Que diferenca em so 25 seg a mais. Eu retirei a consulta do Java e fiz um procedimento em PL/SQL usando recursos de performance desta linguagem. Usei um java dentro do banco para retornar um resultset e adivinha o que deu? Resposta em menos de 1 seg… Bom se foi a melhor maneira não sei dizer, mas que os usuários e o cliente gostou isso eu te garanto. A web ficou mais rapida que o proprio ERP deles… :shock:
[]'s
Bom, mas simplesmente dizer que usando programacao normal leval x segundos, e usando direto no banco leva x / 10 eh meio estranho, pois alguem pode alegar que o teu codigo estava mal escrito
Por exemplo, a infame aplicacao PetStore, que a MS adora usar como argumento contra o Java…
a primeira versao da MS ja comecou usando procedures, fazendo altos precessmentos no banco, enquanto o pessoal da Sun/Java lovers alegavam que isso nao era correto, que a versao em java era independente, que nao era pra mostrar performance mesmo…
Entao vem a Oracle, faz uma versao dela… bom, a historia todo mundo conhece e ja ta de saco cheio…
Mas um ponto que daria pra levantar eh: a versao com a logica feita em java apresentava ser mais lenta que com a logica no banco… Certo ou errado? sei la, nao tenho experiencia nem argumentos pra dizer algo de fundamento em relacao a isso.
Codigo mal escrito pode estar em qq dos lados, e sempre tera algum rebatendo as acusasoes…
Enfim… nao to dizendo que banco eh melhor que java ou java eh melhor que banco… nao to afim de apanhar em plena sexta-feira …
Rafael
Olá
Fábio, belo exemplo do uso de uma solução adequada para o problema do cliente. Já passei por situações semelhentes. Na verdade as vezes nossa consulta precisa de um só valor vindo como resultados de várias consultas. É quase impossível conseguir igualar ao desempenho das consultas rodando dentro da base sem precisar abrir conexão.
Já os caso citados pelo CV também são interessantes e mostram que não se pode dizer que o uso de SP sempre será o mais adequado. O uso de mais de uma base de dados é comum com quem desenvolve softwares genéricos para uso de terceiros. Neste caso o uso de SP pode ser um tiro no pé.
Voltando à questão inicial colocada pelo LIPE acho que só poderia responder de forma consciente se soubesse de mais dados do sistema dele e sua arquitetura.
[]s
Luca
[quote=“Luca”]
Voltando à questão inicial colocada pelo LIPE acho que só poderia responder de forma consciente se soubesse de mais dados do sistema dele e sua arquitetura.
[]s
Luca[/quote]
Com certeza!
Complementando também o Rafael, acho que somos todos a favor de analisar sempre a melhor condição…
Se o objetivo é diminuir o tráfego na rede com a transmissão de um resultado apenas, como citado anteriormente, realmente eu concordo.
O que eu não acho muito visionário é apostar suas aplicações em Stored Procedures. Afinal, como será o futuro dos SGBDs?
Abraços!
Qual o problema com WebServices, Rafael? Nao entendi o que vc viu de tao heretico aqui.
Soh falta dizer que usar Java eh mais rapido do que usar Assembly.
[quote=“Rafael Steil”]Pega um cara que manja de banco de dados e ele te da milhares de argumentos, e testes, e mais argumentos que deixar no banco e melhor.
Entao pega um carinha que odeia essa idea e ele te dara milhares de argumentos que eh melhor soh trabalhar com objetos.[/quote]
Eu nao quero milhares de argumentos, eu quero alguem que chegue pra mim com uma prova de que usar stored procedures eh melhor do que fazer a coisa num application server. Soh isso. Nao precisa ser um caso generico, pode ateh ser um caso estupidamente especifico, eu vou entender. Eh soh provar, e a discussao acaba. Simples. Caso alguem queira que eu prove que stored procedures sao uma merda, beleza 
Quanta resposta boa
E quanto ao sistema, haverá uma quantidade semelhante de consultas e gravações … bom, eu posso muito bem fazer uma gigantesca bateria de testes
Em relacao aos WS em specifico, nenhum. O ponto era sobre usar webservices como “solucao” para a distribuicao de dados, ao inves do banco ( no caso de “nao deixe na procedure, mas sim em um ws” ).
[quote=“cv”]
Eu nao quero milhares de argumentos, eu quero alguem que chegue pra mim com uma prova de que usar stored procedures eh melhor do que fazer a coisa num application server. [/quote]
Eu nao diria que SP eh melhor sempre, assim como nao diria que deixar no app server eh melhor sempre tambem. E tambem nao vou bater de frente com voce ou outra pessoa, ate morrer de tanto rebater argumentos e levar na cara.
Para casos onde voce solicita determinado dado, e o resultado dele depende de consulta a varias tabelas, em um formato “nao-cru” retornado, a procedure pode te ajudar, pois voce ja recebe os dados prontos…
Claro, voce poderia fazer usando objetos, mas sempre tem casos que vc pode dizer: “… pra que?”…
Tem aplicacoes aqui que o cliente pediu especifico - ou seja, nao eh um produto comercial, que visa atender a todos os cliente -, e que roda em determinado banco a pedido/ordem do cliente.
Se algum dia ele mudar de banco - o que eh dificil -, eh soh pagar para ter a nova versao…
Alguns podem preferir fazer por si proprios parte da logica, ou formatacao de dados vindos do banco… eu ja prefiro deixar o trabalho para o dba, se ele quiser… pra que vou ter que me preocupar com isso se ja posso ter o resultado pronto pra usar?
Rafael
Olá
É isso aí!
Nós somos profissionais e precisamos de grana como qualquer outro ser humano para tomar nossas cervejas. Não é anti-ético receber pelo trabalho feito. Então é assim mesmo que deve ser:
[]s
Luca
Até onde é legal jogar as regras de negócio na mão de outra equipe? O DBA vai saber que ele é o responsável pelas regras de negócio da aplicação?
E se sob essas condições não for determinado um banco de dados pelo cliente… Se ele não tiver certeza se vai mudar ou não. Você arriscaria deixar suas regras de negócio em Stored Procedures ou iria preferir WebServices, por exemplo? Ou seja, caso tenhamos a opção nesse caso.
Rafael, Luca, se vcs quiserem discutir os aspectos politicos da coisa, tudo bem, eu entendo. E ate participaria, se eu nao estivesse tentando me importar com os aspectos tecnicos da coisa. Arquiteturalmente, uma stored procedure eh algo tao repugnante quanto colocar todas as regras de negocio em um JSP, e nao tem muito como refutar isso
Sendo assim, vamos a politica da coisa: quem deveria conhecer a logica de negocio do sistema nao eh o DBA. O DBA tem mais eh que se preocupar com tuning do banco e com a manutencao dele - por isso o titulo eh database ADMINISTRATOR, e nao database “programmer”. Do jeito que o Rafael colocou, parece que tanto faz colocar um dba ou um programador pra fazer a coisa, e fica bem evidente que isso eh implorar pra ter problemas (codigo-tripa, alguem?) 
[quote=“Rafael Steil”][quote=“cv”]
Qual o problema com WebServices, Rafael? Nao entendi o que vc viu de tao heretico aqui.
[/quote]
Em relacao aos WS em specifico, nenhum. O ponto era sobre usar webservices como “solucao” para a distribuicao de dados, ao inves do banco ( no caso de “nao deixe na procedure, mas sim em um ws” ).[/quote]
WebServices nao sao para distribuicao de dados. Sao para distribuicao de servicos. Por isso ele se chamam, erhm, WebServices.
O ponto todo aqui eh que nao distribuir os dados nem os servicos (ou seja, travar tudo dentro do banco de dados) te deixa estupidamente amarrado na arquitetura. Se voce esta consciente disso e esse nao eh um problema, entao tudo bem, a vida eh bela, os rouxinois cantam la fora, vc criou um monstro, as violetas continuam a crescer pelo jardim, a empresa vai ter que arcar com os custos horripilantes de ter de reescrever tudo um dia, as criancas brincam de pega-pega na rua, e um cachorrinho abana o rabo pro velhinho que vende algodao-doce.
Com certeza, mas eu naum falei em codigo extra e sim no mesmo SQL…é o mesmo que rodou no java era o mesmo que foi pro banco. O código que eu falei foi criar um java dentro do banco ( o Oracle aceita isso ) e com retornar o que meu SQL retornou, este retorno eu colequei num resultset ou seja conversei com o a parte web na lingua dele JAVA. Nada de código extra para o mesmo SQL.
[]'s
[quote=“cv”]Rafael, Luca, se vcs quiserem discutir os aspectos politicos da coisa, tudo bem, eu entendo. E ate participaria, se eu nao estivesse tentando me importar com os aspectos tecnicos da coisa. Arquiteturalmente, uma stored procedure eh algo tao repugnante quanto colocar todas as regras de negocio em um JSP, e nao tem muito como refutar isso
[/quote]
Nao digo a logica de processamento em si. Me refiro aos dados. Logica da aplicacao eu concordo que ficar no banco eh grudento.
Soh que tambem acho grudendo pegar os dados e via codigo java fazer formatacoes / interligacao de dados, se eles poderiam ja ter vindo no formato “correto”.
Se o ponto disso tudo sempre foi algo do estilo “… verificar no banco de dados se as informacoes enviadas estao de acordo com a especificacao do sistema”, ai sim usar o banco eh no minimo estranho.
Vendo de um outro ponto, se, ao inserir novas informacoes, voce precisa de informacoes de um outro lugar, e para fazer isso voce teria que consultar os seus objetos, popular eles, e entao passar o objeto bonitinho para a camada de persistencia, entao ja me parece melhor passar os dados basicos para a procedure, e ela entao pega os dados que faltam…
Rafael
[quote=“Luca”]Olá
Fábio, belo exemplo do uso de uma solução adequada para o problema do cliente. Já passei por situações semelhentes. Na verdade as vezes nossa consulta precisa de um só valor vindo como resultados de várias consultas. É quase impossível conseguir igualar ao desempenho das consultas rodando dentro da base sem precisar abrir conexão.
Já os caso citados pelo CV também são interessantes e mostram que não se pode dizer que o uso de SP sempre será o mais adequado. O uso de mais de uma base de dados é comum com quem desenvolve softwares genéricos para uso de terceiros. Neste caso o uso de SP pode ser um tiro no pé.
Voltando à questão inicial colocada pelo LIPE acho que só poderia responder de forma consciente se soubesse de mais dados do sistema dele e sua arquitetura.
[]s
Luca[/quote]
O que eu quiz mostrar e esse é meu penssamento…tb sou desenvolvedor Java como todos aqui…adoro usar padrões de desenvolvimento…deixar tudo mais organizado, de facil manutenção…mas existem momentos que não da pra fazer da melhor maneira possivel…
Pense bem como vou explicar para um cliente que meu codigo demora para executar? Quer que eu diga para ele. Bom mas veja bem o código esta bem feito, segue os padrõs…acho que ele não vai engolir ainda mais se essa pessoa for alguem do meio de info que sabe que tem jeito de deixar mais rapido.
Mas meu ponto de vista tb é essa. Essas situações são extremas, é dificil um sistema web ou stand alone usar consultas pesadas desse jeito…esse tipo de processo normalmente roda em background…sem maiores problemas para o usuário final.
Então nós desenvolvedores temos é que fazer isso…achar a melhor situação para cada caso…
[]'s