Melhor forma de desenvolvimento

Se quando você diz utilizar recursos do banco como Trigers, Storeds e etc, você esta querendo dizer deixar alguma regra de negócio no banco, eu me declaro totalmente contra, eu prefiro deixar o BD apenas para armazenar dados, pelo simples fato de que se você deixar regra de negócio no banco e um dia precisar migrar para outro banco, o quê você faz ? terá toda regra de negócio perdida, tenta utilizar o banco para armazenar dados, regra de negócio deixa na linguagem de programação que você estiver usando. Abraços…

No meu caso considero um desperdicio não utilizar os recursos do banco de dados oracle.
Sempre que necessário crio packages pois possibilita uma boa performance

concordo com o que o toredobud falou…

se você for colocar alguma regra de negocio, algo do tipo que va fazer alguma coisa com estes dados antes de gravar num outro banco, eu indicaria fazer isso na linguagem de programação, se você for somente pegar de um lado, aplicando algum filtro se for o caso (na query mesmo) e depois jogar para o outro, ai eu ja indicaria usar a linguagem de programação…

É a eterna luta flexibilidade X performance.
Também prefiro as regras de negócio na aplicação. Porém depende do sistema.
Se a aplicação é muito complexa, é melhor deixar num módulo de regras de negócio. Mas se o banco escolhido for “definitivo” e o cliente não pretende mudar, aproveitar os recursos dos bons bancos de dados é uma boa idéia em se tratando de performance.
Um opção seria deixar no banco e caso precise mudar, pegar os script e adaptar ao SQL do novo banco. Lembrando que dará um trabalhilho e talves nem todos os recursos do antigo estejam no novo banco, ou vice-versa.

Não existe banco permante… hehehe

o que existe é probabilidade baixa de trocar o banco… e mesmo nessas condições deve-se evitar o uso de regras no banco, afinal, seu cliente pode ate querer não migrar, mas e vc ? nunca vai aproveitar as regras de negocio ? em outra aplicação ?? e mesmo se não for, não se amarre ao banco…

ainda mais nessa nova era que se aproxima no horizonte (claud computer) … apostas hoje em banco permanentes são uma furada sem tamanho…

regras de negócios devem estar no seu app, dificilmente vc irá precisar de alguns ms a mais em um processo mega super complexo com procedures…

Pelo que eu vejo, a única vantagem em utilizar os recursos de Stored Procedures e etc… de um SGBD está na performace do sistema, ja que o utilizaria menos recursos da rede.
Já deixando as regras do negócio na aplicação, eu ganharia em reusabilidade de código, independência do BD para possível migração.

Ja trabalhei em varias empresas de grande porte e nenhuma deles nunca congitou a mudança de banco de dados , por isso , acho mais facil mudar a aplicação do que o banco de dados.
So para dar um exemplo na empresa onde trabalho existe as seguintes linguagens de programação : Delphi , Visual Basic, C# e Java.
O Banco de dados sempre foi ORACLE.

Novamente mais uma sobre esse tema, já briguei muito com professores de Faculdades e Analistas que insistiam em querer dizer que uma boa aplicação é aquela que deixa as REGRAS NO BANCO DE DADOS, e o motivo como sempre falam da Performace…
Acho que ficou claro que não é muito “aconselhavel” deixar as regas no Banco, porque ??

• Manutenção Altamente custosa e estressante. Se tiver um BUG em uma trigger/procedure que cuida da lógica, e essa aplicação tem uns 100 cliente espalhados, vc vai ter que dar manutenção em 100 bancos diferentes ??? O fato de não se ter uma linguagem madura como java com uma série de recursos, boas ferramentas para a escrita dos códigos (menos erros), ferramentas de Testes como JUNIT, etc …

• Reusabilidade. Com a Orientação a Objetos pode criar modulos de Aplicação, que podem ser reutilizados em vários projetos. O que seria bem dificil fazer isso no banco.

• Portabilidade (independencia de banco e de S.O), pode-se usar até banco de dados embarcados como Derby, se sua aplicação crescer , simplismente mude o BANCO.

• Performace, esse é o ponto… a favor dos que defendem as regras no Banco, mas nem sembre, se você fizer uma boa modelagem UML (até mesmo DER) é possivel ter uma aplicação com desempenho melhor do que uma que usa as REGRAS no banco. Teve um amigo meu que insatisfeito em ter que esperar de 2h a 4h para emitir um relatório, onde regras da aplicação estavam no BANCO, ele refez o Banco (usando uma boa modelagem orientada a objetos) e usando Hibernate dinimuiu esse tempo para uns 15 a 30seg. E ja vi casos onde a melhoria foi ainda melhor , mais não me lembro dos valores para poder mostrar…

Mas concordo que se pode aproveitar recursos dos bancos de dados, em pontos críticos de sua aplicação, vc pode usar algum recurso desses, MAS CUIDADO…

Realmente eu tb não concordo com as regras de negócio explícitas em banco de dados, porém há casos e casos… talvez em alguma extração de relatório ou pesquisa, mas muiiito talvez.

Tornam-se aplicações difíceis e caras de mantes na mioria daz vezes, sem falar da probreza sintática e semântica das linguagens PROCEDURAIS dos banco de dados