Arquivo Discussoes de Programacao e Tecnologia 
Olá pessoal!!
Aqui na empresa onde trabalho, há uma grande discussão sobre utilizar Java para processar as regras de negócio (por exemplo, em Applications Servers com EJB’s) ou colocar tudo em procedures no banco.
Alguém tem exemplos reais sobre as vantagens e desvantagens de ambas abordagens?
Qualquer opnião sobre o assunto será de grande ajuda.
Obrigado!
Depende da empresa. Não é qualquer um que consegue usar gatilhos com facilidade, e é por isso que DBA ganha bem. De qualquer forma, acho java uma linguagem muito boa para se aplicar regras de negócio no código, até porque é muito mais fácil de entender do que uma procedure para intermediários em SQL.
Eu sou da opnião que as regras de negócio devem estar todas na aplicação. Motivos:
Facilidade de Manutenção (Procedures, principalmente encadeadas por triggers etc etc, são muito dificeis de dar manutenção.
Procedures não são OO, se o seu sistema for Orientado a Objetos, facilita o entedimento de todos, inclusive de futuros desenvolvedores.
No Java temos o JavaDoc (somente ele não serve como documentação do sistema mas pode ser bem útil)
Liberdade de Banco de Dados, se um dia, quem sabe forem trocar de banco de dados não terão que reescrever as procedures e triggers, e vc utilizar JPA ou Hiberate eles automaticamente criaram as tabelas para o novo banco.
Conclusão: Utilize o Banco de Dados somente como um repositório de dados. Ah… Espere problemas com seu DBA. 
Obs: SEMPRE HÁ EXCEÇÕES, processamentos em batch muito pesados talvez valham mais a pena serem feitos através de procedures, mais considero está sempre a última opção.
Olá alévi,
na minha opinião as regras não deveriam ficar no banco de dados, e sim em uma camada de negócios em que eu pudesse, “em teoria”, manter e extender com maior facilidade. Pelo o que eu entendi a questão não é nem essa, e sim se alguem já viu uma implementação com java em que a camada de negócios e não o banco, realize um processamento muito pesado. Cite exemplos, e se possível uma ideia geral de como foi feito …
Não temos outra saída nesses casos se não correr pro banco?
Acho que é nessa linha que a discussão fica mais interessante
Podemos fazer em batch… com agendadores. Ex: Quartz
Não temos outra saída nesses casos se não correr pro banco?
Podemos fazer em batch… com agendadores. Ex: Quartz
voce poderia dar uma explicada com mais detalhes?
Obrigado!
Olá alévi,na minha opinião as regras não deveriam ficar no banco de dados, e sim em uma camada de negócios em que eu pudesse, “em teoria”, manter e extender com maior facilidade. Pelo o que eu entendi a questão não é nem essa, e sim se alguem já viu uma implementação com java em que a camada de negócios e não o banco, realize um processamento muito pesado. Cite exemplos, e se possível uma ideia geral de como foi feito …
Não temos outra saída nesses casos se não correr pro banco?
Acho que é nessa linha que a discussão fica mais interessante
Conselho de quem está sofrendo muito com sistemas legados: Fuja de regras de dados no banco. Triggers, stored procedures e etc começam a se proliferar, e depois ninguém sabe aonde o dado foi alterado, por que…etc…
Aqui na empresa nós temos um caso de processamento bem pesado que é implementado em Java. Suceso cara…
Você pode optar pelo mais simples e usar threads para paralelizar as atividades, ou usar um framework para fazer esse trabalho pra você(EJB por exemplo).