Estou trabalhando em um cliente que basicamente depende de procedures em todos os projetos. Fiquei pensando que talvez essa não fosse a melhor alternativa, pois se eu for olhar para todos os sistemas aqui, todos eles dependem de centenas de procedures com milhares de códigos sql-ansi.
Vcs acham que vale a pena um cliente ficar dependendo de tanta procedure? Pois como todos devem saber, dar manutenção, debugar, alterar uma procedure grande, que tem varias chamadas para outras procedures é algo extremamente difícil.
Use stored procedures apenas se for uma procedure bem otimizada, e que no momento vc não pode transferir pra sua aplicação.
O uso de procedures no banco geralmente vem com o argumento de velocidade, mas esse argumento ja foi batido.
Procure no google por “Java Stored Procedures”.
[quote=fabiocsi]Use stored procedures apenas se for uma procedure bem otimizada, e que no momento vc não pode transferir pra sua aplicação.
O uso de procedures no banco geralmente vem com o argumento de velocidade, mas esse argumento ja foi batido.
Procure no google por “Java Stored Procedures”.[/quote]
Então…era nesse ponto que eu queria chegar. Aqui já tem um pessoal velho de empresa que acha que pra tudo devemos usar procedures, sem exceção. É um pessoal antigo, da época do cobol e isso me deixa fulo da vida, pois dar manutenção em procedures é verdadeiramente um saco. Infelizmente não posso mudar essa mentalidade, pois já é uma coisa de anos e anos. E existem milhares de códigos em procedures…
claro que isto é um problema… trabalhar com procedures e um saco… ainda mais com procedures chamando outra centenas de procedures… acho isso um puta erro de arquitetura… pra mim banco so serve pra armazenar, alterar, e pesquisar dados… a logica de negocio tenque estar na aplicação… o banco é feito pra armazenar as informações deixar logica de negocio em procedures posso estar errado mais ao meu ver não é algo bom… aqui no meu trampo tbm tem muita procedure e o pior trigers com regras de negocio… e isto as vezes da muita dor de cabeça a qual daria bem menas se estivessem no codigo java e nao no banco…
Depende do caso.
Se o sistema nasceu no bd e ja tem SP’s que funcionam, usa-las não é um problema. Existem sim situações onde processamento no bd vai ser melhor.
O problema é espalhar a logica pelo sistema. Ou fica no BD ou fica na aplicação. Dar manutenção em SP’s(se vc conhece a linguagem logico) pode ser tão ruim quanto em codigo java, depende de como foi implementado.
Erro de arquitetura é não otimizar recursos ou escolher ferramentas certas p/ problema certo.
Mas como falei, não existe bala de prata, depende muito da situação. Sem saber exatamente o que o sistema vai fazer e o que ja esta implementado é dificil de saber.
No meu antigo trabalho, os caras que trabalhavam comigo desenvolveram um sistema usando a seguinte arquitetura:
Uma classe por exemplo Client que tinha um metodo salvar que chamava um metodo salvar dentro de uma classe ClienteDAO e que esse metodo por ultimo chamava uma procedure no banco com o mesmo nome pra fazer a persistencia no banco!!! HAHAHAHA
No final era Cliente.salvar() -> ClientDAO.salvar() - ProcSalvarClient(MySQL).
Ao meu humilde entendimento isso eh a maior burrice do mundo!!!
Pior que quando eu falei que nao concordava e apresentei argumentos plausiveis porque eu achava que isso era burrice, todo o grupo ficou emburrado e no final acabaram convencendo a minha chefe (que nao era da area de TI) que fazendo dessa forma a gente nao ficaria dependente de linguagem de programacao!!! AHHHHHHHHHHHHHHHHHH!!! Todos os dias ouvindo tanta abobrinha ficva com vontade de dar um tiro na cabeca!!!
[quote=windsofhell]No meu antigo trabalho, os caras que trabalhavam comigo desenvolveram um sistema usando a seguinte arquitetura:
Uma classe por exemplo Client que tinha um metodo salvar que chamava um metodo salvar dentro de uma classe ClienteDAO e que esse metodo por ultimo chamava uma procedure no banco com o mesmo nome pra fazer a persistencia no banco!!! HAHAHAHA
No final era Cliente.salvar() -> ClientDAO.salvar() - ProcSalvarClient(MySQL).
Ao meu humilde entendimento isso eh a maior burrice do mundo!!!
Pior que quando eu falei que nao concordava e apresentei argumentos plausiveis porque eu achava que isso era burrice, todo o grupo ficou emburrado e no final acabaram convencendo a minha chefe (que nao era da area de TI) que fazendo dessa forma a gente nao ficaria dependente de linguagem de programacao!!! AHHHHHHHHHHHHHHHHHH!!! Todos os dias ouvindo tanta abobrinha ficva com vontade de dar um tiro na cabeca!!!
Sorte que eu sai de la.
//Daniel
[/quote]
Pois é…eu penso em fazer isso aqui…tentar abrir os olhos do meu gerente. Mas tem uns 15 neguinhos aqui q só sabem trabalhar com pl/sql.
[quote=rodrigoy]A função do banco de dados é guardar dados… Stored Procedures é um câncer dentro dos sistemas…
[/quote]
Rodrigo,
discordo disso, essa generalização não é boa.
Existem situações onde SP’s resolvem. E dei o exemplo de algo legado. Hoje eu não começaria um sistema pensando em SP’s, mas as vezes reaproveitar algo ja implementado é uma boa opção.
Mas eu não faria um sistema de BI todo na minha aplicação java por exemplo.
Como falei, existe casos e casos. Generalizar nunca é uma boa.
Qual? (geralmente eu não suporto o custo te manter versões de várias SPs em vários dbs).
Então… é a situação que sou absolutamente contra. Já ví empresas diminuindo margens de venda ao ridículo por conta do fornecedor do banco de dados. Amarrar aplicação com um banco de dados (vendor lock-in) é um tiro no pé. Ansi, em se tratando de stored procedures não é tão Ansi assim.
Bom, legado concordo com você, mas, a coisa mais comum do mundo são SPs com 3000 linhas. Pode ser que vale o custo refatorar.
