Stored Procedures

mete tudo num JSP ou numa telinha gerada pelo netbeans, jbuilder ou vep, e foda-se

erhm, tah, a maneira mais rapida seria usando uma ferramenta porrada pra te gerar o mapeamento OO/relacional, e os objetos. Ou seja, um desses “gerar entity bean a partir da tabela…”, ou as ferramentas que ja vem no Hibernate.

Entity EJBs num application server bom (o que exclui, erhm, todos os application servers disponiveis :D), ou, sei la, um DAO bem feitinho (coisa tao rara quanto um appserver razoavelmente configurado).

Hibernate, ou dependendo das tuas ferramentas, entity beans

Hibernate

(coro de 5 mil criancas com caras felizes e a boca toda melecada): HIBERNEEEEEITEEEEE!!

Então tentar fazer as coisas com stored procedures não é a melhor idéia?

ps.: com “mais rápida” eu quis dizer mais veloz no processamento

ps.: mrgreen pras criancinhas :mrgreen:

“LIPE”:

Então tentar fazer as coisas com stored procedures não é a melhor idéia?

ps.: :mrgreen:

Meu, store procedure eh boi de dar manutençao, MAS SO NA SUA LOGICA. Ou, claro, dependendo de como vc fez.

Eu ja fiz algumas coisas onde praticamente tudo fica na SP, entao qualquer alteraçao era so alterar na SP. Mas sei lá… :roll:

É mto bom jogar um pouco do processamento no banco… :twisted:

Eu aconselho regra de negocio no banco: selects, updates, deletes: fora.

Dei minha opniao.

Valeu brlima

É que eu acho tão bagunçado … e estamos nessa fase de discussão do projeto … e fora o argumento citado eu não tenho mais nada contra Eles hehe

Reutilização de codigo!

E se vc quiser fazer uma aplicação em outra linguagem, utiliza os mesmo conceitos, chamando procedures para, validação por exemplo…

Esse foi o argumento mais forte que usamos, e ganhamos…r.s…

Trabalhei num projeto: Swing + webstart + servlets + procedure. Rapido, limpo e facil manutenção

E se quiserem fazer em jsp, ou whatever, é so validar pelas procedures, etc… menos trabalho na regra de negocio. Só de faz o front end. Certo ?

Eu utilizaria EJBs para fazer as regras de négocio, não costumo utilizar SPs porque sempre que as utilizo a empresa que eu estou resolve migrar o banco de dados e lá vai eu refazer as milhares de procedures. Então na minha opinião a melhor, mais segura é utilizando EJBs. Uma boa opção de velocidade nos dados é perstencia.

Cara, eu vou adorar esse topico. :twisted:

Hmm. E o que vc faz se tiver que trocar de banco ou se tiver que distribuir a carga de processamento das regras de negocio pra outras maquinas fora da sua rede? KABOOOOOM.

Legal, mas o seu argumento eh uma bosta. Simples assim. O que vc queria era usar session bean + webservices, ou um rule engine, e nao um amontoado de stored procedures.

PS: nao tentem me convencer de que stored procedures sao uma boa ideia. Eh perder tempo. Serio. Gato escaldado tem medo ate de agua fria

Acho que se você vai amarrar em algum lugar, amarra na linguagem e não no banco de dados. Se vamos desenvolver pensando em reutilização, por que não utilizar todos os recursos que uma linguagem possa nos dar para isso?

Amarrando as regras de negócio no banco de dados estaremos criando uma forca: a tendência dos BDs com a criação destes frameworks para acesso a dados, vai ser ficar cada vez mais independente da aplicação… Imagine-se daqui a 5 anos reescrevendo suas Stored Procedures

Abraços!

Ei oazuc, os caras aqui e vc me convenceram… Mas que fique claro que eu acho que a merda de usar asp é tão grande que tende ao infinito, logo usando stored procedures ou não, não vai tirar-nos da merda

Abraços,
Tiago Serafim

Caramba cv, vc vem com os dois pés no peito…rs :shock:
Meu, acho que ninguem troca de banco como troca de cueca, pelo menos grande parte das empresas que conheço, nunca trocaram de banco. É mais facil vc encontrar um banco para varias linguagens…
No caso de distribuição do processamento, acho que é coisa do grid computing, ou to falando merda ?..rs…

Ah, num fala mal das procedures… :roll:
Acho que uma boa distribuição nao faz mal a ninguem. Ateh hj ninguem reclamou

Mas é serio cv, acho que é mais facil ( e certo ) vc ter uma base com seus dados e regras para poder ser livre e facil desenvolver seus fronts… :roll:

Quanto tem muito processamento batch procedures são mais velozes, porem você terá muitos efeitos colaterais:

1 - Se você desenvolver em PL/SQL ou Transact-SQL por exemplo, você estará amarrando sua logica a um fornecedor.

2 - Por mais que se tente, é dificil escrever codigo limpo, reutilizavel e padronizado com procedures.

3 - Se você trabalha com oracle um bom IDE pra desenvolver é mais caro do que os melhores IDE’s javas.

4 - Debugar prrocedures grandes pode se tornar uma grande dor de cabeça.

Agora se meio segundo no seu projeto for fundamental, fazer o que!

Estou vivendo um inferno destes…
Tenho um produto que é um sistema de gestão estratégica e como tal, deve se adequar a qualquer tipo de empresa certo???
este produto não foi “encomendado” por um cliente.
pois é…

Tinhamos o Sistema todo em procedures para ORACLE.
Resultado.
1º Cliente - SQLServer
2º Cliente - SyBase
3º Cliente - ORACLE :twisted:

Simplesmente um inferno criar toda regra pra cada banco…

Solução que adotamos:

• Criamos arquivos .properties para cada banco.

hehe eu não sei se entenderam minha queixa, mas eu sou contra usar stored procedures para tudo exatamente pelo que falaram … e principalmente por causa da bagunça … se ficar 1 semana sem olhar para o código não entendo mais nada depois … mesmo com mais linhas de comentários do que de código :mrgreen:

Valeu queridos

De nada, de nada

Um “causo” pra vc: numa empresa em que eu trabalhava, um belo dia desses o diretor-geral-mega-master-pokemon-evoluido proclamou “não usamos mais nada proprietário”. Advinha o que aconteceu com as TONELADAS de procedures dentro do SQLServer?

Tah, tudo bem, mesmo assim, o seu argumento eh valido: eh bem mais comum usar varias linguagens pra um banco de dados. Mas se todo mundo se jogar da ponte, vc vai simplesmente se jogar tambem? Que custa colocar o diacho da regra de negocio dentro de uma aplicacao J2EE, e dar uma camada de webservices pra que as outras linguagens possam acessar? Assim, a sua regra de negocios fica em um lugar, os dados em outro, e todo mundo fica feliz. Alem das suas aplicacoes como um todo se tornarem bem mais faceis de gerenciar.

Ah, claro, mais uma vantagem: usando J2EE direito, vc fica independente de banco de dados e tambem de application server.

Pode ser, mas nem eh necessario chegar a esses extremos. Afinal, tem muita regra de negocio em que um middleware (no caso, o servidor de aplicacoes) pode processar muito bem, com uma grande vantagem sobre fazer tudo no banco de dados: o appserver estah mais proximo do cliente do que o banco. Alem, eh claro, de vc ter uma linguagem estupidamente mais expressiva pra modelar as suas regras de negocio (convenhamos, quem programou em PL/SQL sabe do que eu tou falando ;))

“brlima”:

Ah, num fala mal das procedures… :roll:
Acho que uma boa distribuição nao faz mal a ninguem. Ateh hj ninguem reclamou

Ate hoje ninguem reclamou da gravidade tb, mas eu particularmente nao acho ser legal ser puxado pra baixo o tempo todo. Se ninguem reclamou eh pq ninguem percebeu que uma arquitetura com mais camadas te da muito mais flexibilidade, quando o seu software eh bem feitinho.

Ter uma base com os dados, legal. Ter outra base com as regras (nesse caso, o seu application server), melhor ainda.

Serio, ate hoje ninguem me deu um exemplo onde eh irrefutavelmente melhor usar uma stored procedure. Nem mesmo quando se fala em performance. Ninguem me mostrou ate hoje o mesmo codigo escrito com Session + Entity ou Session + Hibernate e stored procedures, chegou pra mim com dados REAIS* de performance e me disse “eh, fodeu.”

*REAIS = verificaveis. Eu quero poder ir ate a maquina e ver as configuracoes todas, caching, pooling, controle de transacoes, tudo.

Em aplicações feitas sob medida para uma unica empresa…essas que elas pagam uma grana preta para desenvolver…o melhor é deixa no banco mesmo. Me diz ai qual empresa que troca de banco de dados? Eu perticularmente não conheco nenhuma.

Agora se vc vai desenvolver uma aplicação para vender…no banco só se for loco…

Sei que o pessoal do naum curte muito largar no banco os SQL, por causa de reusabilidade do código…isso até é uma verdade, mas que estando no banco é mais rapido isso sem duvida. Ainda mais se o baco for Oracle.

[]'s

É isso que estou perguntando …

Concordo com vc, cv, realmente webservices é o bicho! :twisted:

Bem, “existem mil maneiras de se fazer neston, invente a sua!”.

Provas. Eu quero provas.

Provas. Eu quero provas. ;)[/quote]

voce esqueceu do…
“e não venha com chorumelas!” :lol:

Provas. Eu quero provas. ;)

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

“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

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.

“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.

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” ).

“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.

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?)

“Rafael Steil”:

“cv”:

Qual o problema com WebServices, Rafael? Nao entendi o que vc viu de tao heretico aqui.

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” ).

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

“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

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

“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

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

Desculpe-me pela ignorância, mas… Você rodou Java no Oracle e ficou mais rápido do que no application server?

Por favor, me corrija se estiver errado!

Abraços!

O Oracle tem recursos para o código java. Inclusive tem um application Server da Oracle que é considerado o application server mais rápido do mercado.

“oazuc”:

“fabgp2001”:

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.

Desculpe-me pela ignorância, mas… Você rodou Java no Oracle e ficou mais rápido do que no application server?

Por favor, me corrija se estiver errado!

Abraços!

Não…o que ficou mais rapido foi o SQL rodando no banco…mas para retornar ao Java os registros eu usei um java retonando um resultset.

[]'s

“Rafael Steil”:

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

desculpe pela insistência, mas estes campos adicionais podem ser considerados regra de negócio também! Imagine que de uma hora para outra determinado dado como o número de celular que antes era pesquisado pela SP que insere a venda deixa de ser necessário para o negócio da empresa? É claro que é um exemplo bem trivial, mas poderia acontecer com registros mais complexos… Daí toca o pessoal da programação notificar o DBA para modificar as SP pra gente!

Até concordaria em deixar alguma coisa que acessa os dados e não é regra de negócio no banco… Só não consigo imaginar nenhuma situação desse tipo (é que já é sexta à tarde )

Meu Deus, o q seria de nós sem a ORACLE… gente, vamos rezar para ORACLE não quebrar!!! :agrue:

O maior problema que eu vejo com é a mentalidade que vem associada junto. Todo desenvolvedor que usa OO costuma ter asco ao modelo relacional e toda porcaria associada a ele.

Oque eu costumo ver com o pessoal que usa muita SP é estar com a cabeça ainda engeçada na droga do modelo relacional, alem de ser incapaz de dissociar persistencia com um RDBMS, não aceitando que fazer persistercia de dados em qualquer outro meio.

Dos casos onde ter uma SP supostamente deixa mais rápido, eu não conheço um onde o problema é o fato do modelo de dados mapear muito mal para o relacional; uma estrutura hierarquica é um ótimo exemplo disso, com varias pesquisas envolvendo muitos niveis via SQL a performance vai ser sempre uma droga pq vai envolver toneladas de join, enquanto que usando, por exemplo, um servidor de diretorios, tais pesquisas seriam triviais.

Agora convercer um cara que usar um banco relacional é uma má idéia me parece mais dificil que fazer o cv gostar de stored procedures.

Olá

Amigos, desculpem-me o off tópic mas não posso deixar passar esta.

CV, apesar da mistura do “te” com "“você”, muito obrigado por este delicioso parágrafo:

Adorei a oportunidade de saborea-lo. Tecnologia com criatividade e inteligência. Já valeu minha vinda aqui hoje.

[]s
Luca

Opa, mas nesses casos voce sempre precisara do DBA… se tiver que alterar a tabela, quem ira fazer isso? se a empresa tiver um DBA, nao sera voce…
Esses casos de “ah, mas se isso um dia mudar”… entao, quando esse dia muda, voce vai la e muda, assim como tera que mudar as regras da tua aplicacao.

Veja pelo outro lado: voce faz tudo via objeto… entao alguem decide que determinadas tabelas nao sao mais necessarias, ou camps sao mudados/adicionados… nesse caso, o DBA tera que ir ate o programador e pedir para ele alterar.

Voce tera esse tipo de problema em qualquer das situacoes… Se quiser evitar, nao use banco de dados.

Rafael

Pééééé. Resposta incorreta. Um DBA eh administrador, e nao engenheiro. Ele nao cria a base, ele a mantem funcinoando. Mesma diferenca entre um administrador e engenheiro de redes. Sao conhecimentos distintos. Se o DBA da sua empresa brinca de dublê de DBE, entao tem alguma coisa errada.

Olá

CV, pelo preço que a gente paga ao DBA quando precisa de um aqui na empresa o cara instala o banco, cria a base, otimiza tudo e ainda limpa os banheiros.

[]s
Luca

Pééééé. Resposta incorreta. Um DBA eh administrador, e nao engenheiro. Ele nao cria a base, ele a mantem funcinoando. Mesma diferenca entre um administrador e engenheiro de redes. Sao conhecimentos distintos. Se o DBA da sua empresa brinca de dublê de DBE, entao tem alguma coisa errada.

Ta certo, viajei grandao. Mas nesse caso entao nao sera ele que fara a procedure tmb. Troque “dba” por “carinha que cuida do banco do sistema”.

Rafael

Ah sim, aquele figurao mitico que de vez em quando tenta mover objetos por aih com a forca do pensamento, passa semanas frustrado por ainda nao ter conseguido, e desconta a raiva nos programadores. Geralmente o salario dele tah bem longe disso, mas por aqui a gente chama esse cara de “babysitter de oracle”, pq no fundo no fundo tudo o que ele faz eh isso. Tambem conhecido como Orasitter

Ei, olhem! Eu tenho DOIS pirulitos!

oferece um para o cvpotter e outro para o steilar

:mrgreen:

“louds”:

Oque eu costumo ver com o pessoal que usa muita SP é estar com a cabeça ainda engeçada na droga do modelo relacional, alem de ser incapaz de dissociar persistencia com um RDBMS, não aceitando que fazer persistercia de dados em qualquer outro meio.

Dos casos onde ter uma SP supostamente deixa mais rápido, eu não conheço um onde o problema é o fato do modelo de dados mapear muito mal para o relacional; uma estrutura hierarquica é um ótimo exemplo disso, com varias pesquisas envolvendo muitos niveis via SQL a performance vai ser sempre uma droga pq vai envolver toneladas de join, enquanto que usando, por exemplo, um servidor de diretorios, tais pesquisas seriam triviais.

Agora convercer um cara que usar um banco relacional é uma má idéia me parece mais dificil que fazer o cv gostar de stored procedures.

Louds,

A maior parte do meu tempo com info foi desenvolvendo com banco, mas tb usando java.
Apesar disso eu naum tenho esse pensamento que vc disse ai em cima, estudo outros metodos de armazenamento, bancos oo, persistencia em XML e tudo mais, mas tenho um pensamento realista. Ja que tocou neste ponto me diz ai como armazenar 70GB ou mais de info sem ser em um banco de dados relacional? Como montar um DW sem ser em um banco relacional? Existe essa solução hoje em dia?

[]'s

Pééééé. Resposta incorreta. Um DBA eh administrador, e nao engenheiro. Ele nao cria a base, ele a mantem funcinoando. Mesma diferenca entre um administrador e engenheiro de redes. Sao conhecimentos distintos. Se o DBA da sua empresa brinca de dublê de DBE, entao tem alguma coisa errada.

Isso depende de cada empresa: se eh uma com um MIS pequeno, entao o DBA é o cara do banco, das procedures, no explorer, da rede…rs… Mas em empresas grandes, DBA só pra ADMINISTRAR mesmo!, Tipo, vc cria e manda o cara compilar; Retirar colunas é com o cara… etc…

Aew,

Me desculpa…mas quem nunca trabalhou com algum produto Oracle direta ou indiretamente? Se nunca fez isso provavelmente nunca trabalhou para uma grande empresa.

[]'s

E o ponto em que vc esta querendo chegar aqui eh…? Que a Oracle eh grande e tem uma penetracao no mercado enorme? Uh… legal, mas nao sei no que isso se encaixa na conversa

PS: cacete, como eu tou troglodita hoje. preciso tomah uns prozacs.

Em aplicações feitas sob medida para uma unica empresa…essas que elas pagam uma grana preta para desenvolver…o melhor é deixa no banco mesmo. Me diz ai qual empresa que troca de banco de dados? Eu perticularmente não conheco nenhuma.

Agora se vc vai desenvolver uma aplicação para vender…no banco só se for loco…

Sei que o pessoal do naum curte muito largar no banco os SQL, por causa de reusabilidade do código…isso até é uma verdade, mas que estando no banco é mais rapido isso sem duvida. Ainda mais se o baco for Oracle.

[]'s

Affff queimei a lingua…

FUi falar que dificilmente uma empresa muda de banco e a propria que estou trabalhando me vem com essa noticia oh vida…

O pior de tudo, não adiantou nada deixar as regras de negocio fora do banco la no java tudo bunitinhu…vaum trocar a tecnologia tb…e imaginem pra qual??

arhhhh…estou orfão …acho que vou fazer as malas e tentar a sorte em outras bandas…

Ps.: Garanto que foi praga do CV…hiauhaiuhai zuera loco.

[]'s

“louds”:

Agora convercer um cara que usar um banco relacional é uma má idéia me parece mais dificil que fazer o cv gostar de stored procedures.

Acho que o louds se referia à utilizar regras de negócio no bd e não “não utilizar bd relacional”. Se entendí errado me corrija louds…

“fabgp2001”:

Aew,

Me desculpa…mas quem nunca trabalhou com algum produto Oracle direta ou indiretamente? Se nunca fez isso provavelmente nunca trabalhou para uma grande empresa.

Uhhhhh… essa doeu… mas brincar com ORACLE eu faço no meu desktop. Não estou desprezando a tecnologia não, eu sei muito bem a grande fatia que os caras tem no mercado… cá pra nós, vc acha que por trás das maiores instituições financeiras (pra não dizer todas) roda o quê??? ORACLE ou o produtinho de 3 letras da big blue?

E o ponto em que vc esta querendo chegar aqui eh…? Que a Oracle eh grande e tem uma penetracao no mercado enorme? Uh… legal, mas nao sei no que isso se encaixa na conversa

PS: cacete, como eu tou troglodita hoje. preciso tomah uns prozacs. :D

Não não cv…eu so fiz um comentario a uma reposta la atras de um colega…onde ele diz o que seria de nós sem a Oracle…
Para mim representa muita coisa…até hoje so encontrei bancos oracle pela frente…

Agora vai chover pedradas hehehe…

Blz…mas entendo que naum esta no escopo do assunto…

[]'s

“fabgp2001”:

Louds,

A maior parte do meu tempo com info foi desenvolvendo com banco, mas tb usando java.
Apesar disso eu naum tenho esse pensamento que vc disse ai em cima, estudo outros metodos de armazenamento, bancos oo, persistencia em XML e tudo mais, mas tenho um pensamento realista. Ja que tocou neste ponto me diz ai como armazenar 70GB ou mais de info sem ser em um banco de dados relacional? Como montar um DW sem ser em um banco relacional? Existe essa solução hoje em dia?

[]'s

Claro que existe essa solução hoje! Bancos OOs são uma realidade e alternativa viavel a banco relacionais, já lí casos de sucesso com bases gigantescas e performance muito boa.

Servidores de diretorio, LDAP, são outro caso. Existem deployments com diretorios na ordem de 1 tera, a CNN é um bom exemplo disso. Os requisitos de performance não seriam possiveis usando ums RDBMS.

Bom, vou colocar fatos

http://www.wintercorp.com/vldb/2003_TopTen_Survey/TopTenWinners.asp

Na categoria de maiores bases hibridas, temos:

Um banco de 0,8 pentabyte é suficiente para voce? Ele roda um banco OO.

Ahhhhh!, por isso o site da cnn eh mais lerdo q conexao 14400… hmmmmm…

Eles usam NDS para fazer autenticação, autorização e personalização. São 2000 queries por segundo, com tempo de resposta inferior a 250ms, em um diretorio com milhões de objetos.

Eles usam NDS para fazer autenticação, autorização e personalização. São 2000 queries por segundo, com tempo de resposta inferior a 250ms, em um diretorio com milhões de objetos.

Eu tenho uma curiosidade muito grande com relação ao Google. Você tem esses dados deles??? Quantas querys por segundo, tempo de resposta. E fugindo um pouco de assunto, é verdade que o sistema deles é feito em python ?

Tb já tive essa curiosidade e achei algumas dessas respostas no… Google!

http://www.google.com/press/overview_tech.html

Desviou totalmente do tópico mas tudo bem…

[]'s

quando vcs fazem um sistema p/ o cliente vcs naum projetam o BD tb???

eh muito mais produtivo a programcao em SQL…qnto mais vc puder programar no banco melhor, o processamento do banco eh muito mais rapido q o da aplicacao

c o DBA nao pode fazer nenhuma alteracao (criar o banco) no banco intaum qem vai fazer isso? fazer alteracoes no banco quando necessario (por exemplo mudar uma procedure, criar o banco) nao eh dar manutencao???

otra coisa: SGBD d verdade eh firebird e postgree

oracle soh no caso d aplicacao ser muito muito grande, pq ele eh caro pra burro

Olá

Alguns conselhos de um velho marujo:

1. Programar em SQL não é lá muito produtivo. Talvez você esteja falando de facilidades especiais embutidas em alguns SGDB.

2. Quanto menos você programar no banco melhor pois sua aplicação fica independente do banco.

3. O processamento no banco pode ser mais rápido mas na prática raramente isto acontece. Na maioria das vezes quem programa as stored procedures não é um DBA especializado em performance tunning. Então na maioria das vezes elas NÃO são mais rápidas a ponto de justificar tirar o controle de acesso ao banco dos programadores Java que podem usar frameworks razoavelmente produtivos.

O uso de stored procedures só se justifica quando se quer isolar regras de negócio dos programadores para evitar vazamentos em caso de saída de programadores da equipe. Por desempenho só vejo utilidade em raros casos de empresas que tem DBAs muito especiais.

[]s
Luca

Lipe,

Algumas vezes é interessante usar SP quando vc quer jogar um
pouco de lógica de programação na mão de quem não sabe Java.

É muito comum nas empresas com Oracle, os programadores só
conhecerem PL/SQL, e terem uma grande facilidade para criar
triggers,functions e SP.

Em alguns casos por facilidade e performance é interessante
dividir a lógica com o banco de dados.

Teve um cliente que não me passou nenhum SQL, simplesmente
mandava a equipe dele criar uma procedure que me voltava
um REF CURSOR e daí eu buscava os dados.

Avalie o seu caso ae…

pra q uma plicacao independente d banco??? quando vc faz um sitema vc projeta o banco junto…agora c ainda assim vc qer q sua aplicacao sirva pra varios tipos d BD, coloque suas sql e suas rotinas d conexao num properties

ta loko… parece q vcs num conhecem nada sobre banco d dados, acham q todos os bancos sao q nem akelas porcarias d access e paradox da vida, q nem SGBD sao…

como o boaglio falou, deve-se dividir um pouco da logica do teu sistema com o banco… 8)

boaglio, obrigado pelas dicas, mas dê uma olhada na data da minha postagem hehe

lich king, na época que estava com essa dúvida, o argumento final para não usarmos stored procedures no sql server foi: se o cliente tiver Oracle, o que falo para ele? “Sinto muito, compre um sql server ou espere 3 meses para refazermos a aplicação toda”. Então preferimos escrever as regras de negócio em Java.

Não sei de qual linguagem de programação está vindo, mas claramente não está percebendo o poder que Java empresta ao desenvolvedor. Meu conselho é: utilize esse poder.

E outra, com essa arrogância toda, para quê você ainda pergunta, se está tão certo de seu conhecimento? Sempre ouvi, principalmente no começo, atentamente aos conselhos de pessoas como o Luca, que tem experiência sobrando e fazem a gentileza de ajudar nós, com tantas dúvidas. Não custa nada abrir um pouco a mente para esse mundo novo que está começando a explorar.

Calma, calma… Não é bem assim, pense no seguinte, supomos q eu coloque parte das minha regras de negócio em stored procedures… Se eu utilizar bancos diferentes como Firebird, Oracle e outros; terei que reescrever o meu código para cada um desses bancos (afinal a linguagem das stored mudam de bd para bd)… Isso com certeza pode ser um grande problema… Vc possui seu sistema pronto para 4 bancos de dados e derepente muda uma regra já implementada… lá vai vc alterar as stored dos 4 bd, ufa, não, muito obrigado!!!

Hoje em dia é bastante normal necessitar de independência de bd, já pensou vc chegar no seu cliente que gastou muita grana em um bd Oracle e dizer pra ele que seu sistema foi feito para o db2 e que ele terá que gastar mais alguns Reais (alguns???)… Acho que ele vai preferir procurar outra software house…

Fallow

Olá

O Boaglio lembrou muito bem do caso especial de empresa que tem mais gente que conheça a linguagem do bando do que programador Java. Eu particularmente nunca vi isto, pelo menos programadores ótimos na base de dados.

Quanto a independência da base de dados quero lembrar que isto é uma vantagem imensa tanto na fase de desenvolvimento como na homolagação e futuramente na produção. Para aqueles que desenvolvem software com potencial de revenda isto passa a ser um requisito muito importante.

Escolher a base de dados no projeto da aplicação é muito bom porque as vezes os requisitos de projeto exigem bases paralelas e de muita capacidade e nestes casos os fornecedores são poucos. Mas minha opinião não foi para os casos especiais de uso de teradata ou oracle paralelo. Falei do caso comum do tipo que tenho aqui com um monte de stored procedures mal escritas, mal documentadas e sem avaliação de stress.

[]s
Luca

Esse ai ta parecendo eu quando cheguei por aqui, queria tudo dentro do banco. :lol:

Se voce entendesse tanto de banco assim nao falaria uma besteira dessa.
Vai reinventar a roda guardar em properties depois ficar lendo eles e criando sql dinamico? Argh se o DBA te ve fazendo isso.

]['s

Bom, experiência pessoal. Na empresa que trabalho, o uso de stored procedures é enorme, São cerca de 1500 stored procedures, grande parte delas com mais de 500 linhas. Banco Sybase e a empresa deu curso de performance tunning para todos os funcionários, sendo que contamos com 2 DBA’s e uma equipe de uns 10 programadores SQL. SIm, equipe especializada. Mas o Sybase não está mais atendendo aos requisitos e será migrado tudo para Oracle. Agora imaginem a cena. 1500 stored procedures, 2500 triggers, umas 1000 tabelas e alguns bilhões de registros tendo que ser migrados. Delícia não? Então se não quer passar por esse tipo de dor de cabeça, deixe sua regra de negócio na aplicação

ah…vcs tao falando do sql server…

tipo, eu num so mto fã d bancos pagos (principalmente c for da m$), prefiro trabalhar com bancos free…(o unico banco pago q eu trabalharia eh o oracle)

num consigo entender esse negocio d vcs fazerem um sist. p/ um banco e o cliente ter outro…

Em que mundo tu vive?? :lol:

Prova de que vc nao tem la muita experiencia na area e deveria ouvir o que ta todo mundo dizendo com mais atencao

Nao da para generalizar. Se for para migrar, a probabilidade da empresa mudar de linguagem eh maior que mudar de banco de dados.

Deixar a regra toda na aplicacao eh sub-utilizar o banco de dados, e vice-versa.

Esse eh o mesmo tipo de discussao sobre “Java x C#”.

Rafael

Nem existe um banco de dados chamado “postgree”. Como vc pode afirmar que o PostgreSQL eh melhor que todos os outros se nem o nome vc sabe direito?

Lich King:

oracle soh no caso d aplicacao ser muito muito grande, pq ele eh caro pra burro

Conceito estranho. O Oracle nao vai resolver todos os teus problemas, e ha situacoes onde um MySQL vai ser melhor que o Oracle.

Rafael

Banco de dados eh como camisinha: uns dizem que tira toda a graca, outros gostam da sensacao de seguranca que ela oferece, mas todo mundo acha horrivel quando usa uma que nao serve direito.

Olá

Saiba que para muitos o Oracle não passa de um sistema gerenciador de base de dados ideal para aplicações de porte limitado em plataformas baixas. Saiba que muito grandes bancos e entidades que precisam realmente de poder usam coisas do tipo de teradata

E pior. Algumas empresas que eu sei precisaram migrar de outras bases que não deram conta do recado.

[]s
Luca

opinião pessoal :

tudo depende do cliente e do que ele esteja disposto a gastar com a solução.Eu,particularmente,gosto muito do oracle.Conheço ele um pouco
e já fiz coisas legais com ele,porem nós não podemos nos empolgar com nossos anseios e complicar as coisas.Como eu disse cada caso é um caso
no final das contas quem deve se dar bem é o cliente que está nos pagando,pois com o sucesso do cliente o nosso sucesso fica evidente.

o que nós sabemos é que não se deve ficar dependente de um fornecedor, incluindo um fornecedor de banco de dados

o q vc qer dizer com dependente d fornecedor d banco d dados??

Ficar dependente eh aquela sensacao esquisita que a gente tem quando, por exemplo, voce nao tem grana pra comprar o BolaDeCristal 11h mas o fornecedor esta pressionando a migracao (mesmo que o seu dez gramas funcione a contento).

Independencia de fornecedor eh uma Coisa Boa™. Se eu deixasse minha esposa comprar Omo todos os meses tava ralado.

Marcio Kuchma

digamos que vc baseie toda a sua aplicação em stored procedures e triggers, deixando boa parte da lógica de negócio para o Banco de Dados

aí, no meio do desenvolvimento, seu cliente resolve trocar de banco de dados, ou então vc mesmo verifique que é melhor usar um outro método de persistencia

aí vc ta ferrado, vai ter que refazer toda a parte de acesso a dados

Rubem, vc tera esse tipo de problema em qualquer situacao. Ate a linguagem de programacao pode mudar ( e costuma mudar mais facilmente que o banco de dados ).

Nao precisa basear toda a aplicacao em procedures, mas sim saber usar corretamente. Sendo visao fechada assim vc estara deixando de usar recursos otimos para muitos casos, escrevendo ( digo, reescrevendo ) codigo para o qual ja existe ferramentas que lidam com a situacao.

Em programacao vc esta sujeito a fazer refactoring de maneira constante, e isso inclue todas as partes envolvidas, seja banco, seja na linguagem de programacao que esta sendo utilizada. Voce soh tem a perder com essa mania de fazer sistemas genericos.

Rafael

o cliente resolver trocar d banco??? desde quando o cliente q decide qual banco usar??? qem tah fazendo o sistema e sabe qual a solucao melhor eh vc e nao o cliente, q eh leigo…o cliente deve t dizer oq o sistema deve fazer e naum como desenvolvê-lo

mudar o método d persistencia no meio do projeto??? mas num eh feito um planejamento/estudo antes d comeca a desenvolver, pra naum acontecer d ficar mudando toda hora d requisitos e especificacoes???

alguem discorda da minha opiniao??? :?:

P.S.: quando eu disse q tava parecendo q vcs naum conheciam nada d BD eu tava qerendo dize q c deixar todas as regras d negocio na aplicacao eu estaria subestimando o SGBD

Eu discordo Lich King.

Clientes que usam bancos de dados pagos nunca vão aceitar que um fornecedor o obrigue a comprar um outro. Uma empresa que gastou 2-3 milhões de reais num servidor com Oracle/SQL Server/DB2/Teradata/outro DMS nunca vai aceitar ter que adquirir outra solução.

Hoje em dia desenvolver um produto que suporte não os 4-5 bancos mais populares é fechar portas antes mesmo de encontrá-las.

1. Existem clientes que nao sao leigos.

2. Existem ambientes em que seu sistema nao sera o pioneiro (primeiro a entrar em utilizacao), pois ja existe todo um ecossistema em pleno funcionamento.

Obviamente em ambos os casos o cliente tera diretrizes que deverao ser seguidas como parte dos requisitos.

Infelizmente o mundo nao eh tao simples.

Marcio Kuchma

Lich King:

o cliente resolver trocar d banco??? desde quando o cliente q decide qual banco usar???

Eh o cliente que paga o teu salario ;). Ele pode perfeitamente decidir qual banco usar, principalmente nos casos onde pagou uma consideravel forturna em hardware e licencas de uso.

Rafael