Regras de negócio na base de dados

Programação Arquitetura
#1

Galera,
O que acham de um projeto onde as regras de negócio são implementadas na base de dados? Gostaria de saber os prós e contras desse tipo de arquitetura.

#2

Na minha empresa todas as regras de negocio estão dentro do banco.

Eu particularmente nao gosto, acho que a manutenção fica mais trabalhosa, acho que fica mais bagunçado, e voce nao consegue usar por completo um framework ORM, por exemplo, que facilita a programação e boas práticas de POO.

O que eu faço na parte do Java, aqui na empresa, é readequar o Java para o Banco, e isso, às vezes nao é legal.

Em alguns processos é interessante manter a regra, como algumas validação com plsql por exemplo.

#3

como assim?
teria um exemplo?

#4

Eu trabalhei 6 anos em uma empresa que tinha um produto com toda lógica implementada no banco, agora que trabalho há quase 2 com a lógica fora de lá, posso dizer que como o Lucas disse tem muitas complicações no que diz respeito a manutenção. E não consegui perceber nenhuma diferença gritante em termos de desempenho com esse modelo que venho usando, o que é muito defendido pelo pessoal que gosta de lógica no banco, dizem que é muito mais rápido.

#5

Bem, isso é até comum, é a chamada programação orientada a BD…
O pessoal enche de Stored Procedure, cursores, functions, views e tudo o que se pode imaginar…
Para aplicações de pequeno e médio porte, tudo bem, agora, transações mais complexas, com muitas tabelas e muitos registros… Fica inviável…

#6

Pois é Lucas, concordo plenamente contigo. Mas me pergunto, ná prática, é de fato melhor na performance? Existe um estudo que comprove isso, pois na teória faz todo sentido mas encontrei nada sobre. Uma das possíveis vantagens que vejo é migração de aplicações Java
como por exemplo GWT para JSF. Você concorda?

#7

É muito mais rápido quando você tem uma base de dados “Godzilazesca”, o que não é o caso de 99% dos projetos que vejo por aí. Na minha opinião, esse papo de que o sistema fica mais rápido com regra de negócio dentro do banco é coisa de desenvolvedor-dinossauro, pra quem o programa só serve pra mostrar ao usuário os dados que estão no banco.

Explico. Vejo muito a seguinte situação: curioso que aprendeu a programar em Delphi/VB através daquelas revistinhas tipo a antiga PC Expert, mas que nunca pensou em aprofundar seus conhecimentos, ou realmente entender o que estava fazendo. Para essas pessoas, o mais importante são “os dados”. Eles usam a linguagem de programação apenas para criar uma tela bonitinha pra mostrar “os dados” para os usuários. E, como brinde, normalmente o banco onde estão “os dados” tem sempre um porrilhão de triggers, procedures e afins, além de tabelas completamente desnormalizadas, redundantes e bizarras.

Acreditem em mim. Eu já vi uma tabela que armazenava datas em três colunas, uma para o ano, outra para o mês e a última para o dia. E a cereja do bolo é que todas elas eram do tipo char.

#8

[quote=fabioEM]Pois é Lucas, concordo plenamente contigo. Mas me pergunto, ná prática, é de fato melhor na performance? Existe um estudo que comprove isso, pois na teória faz todo sentido mas encontrei nada sobre. Uma das possíveis vantagens que vejo é migração de aplicações Java
como por exemplo GWT para JSF. Você concorda?[/quote]

Os DBAs dizem que a performance é melhor. Eu nunca fiz um comparativo, nem achei um bechmark comparativo.

Eu particularmente acho que não há uma diferença de performance.

Agora, pense bem, se voce for usar um Stored Procedure:

1 - Sua Classe Java recebe os Parâmetros.
2 - Sua Classe Java chama o SP (CallebleStatement) e passa o parâmetro.
3 - O Sp recebe os parâmetros, faz o processo interno dele
4 - SP devolve um resultado numa variável OUT ou em Cursor.
5 - Java recebe Resultado e processa.

Talvez usando lógica na aplicação, eliminaria alguns desses passos, e poderia impactar no desempenho. Não sabemos o esforço do Java para encontrar os Packeges e os seus SPs.

ps.
Quanto ao JSF que voce mensionou, eu particularmente, acho péssima opção.

#9

É muito mais rápido quando você tem uma base de dados “Godzilazesca”, o que não é o caso de 99% dos projetos que vejo por aí. Na minha opinião, esse papo de que o sistema fica mais rápido com regra de negócio dentro do banco é coisa de desenvolvedor-dinossauro, pra quem o programa só serve pra mostrar ao usuário os dados que estão no banco.

Explico. Vejo muito a seguinte situação: curioso que aprendeu a programar em Delphi/VB através daquelas revistinhas tipo a antiga PC Expert, mas que nunca pensou em aprofundar seus conhecimentos, ou realmente entender o que estava fazendo. Para essas pessoas, o mais importante são “os dados”. Eles usam a linguagem de programação apenas para criar uma tela bonitinha pra mostrar “os dados” para os usuários. E, como brinde, normalmente o banco onde estão “os dados” tem sempre um porrilhão de triggers, procedures e afins, além de tabelas completamente desnormalizadas, redundantes e bizarras.

Acreditem em mim. Eu já vi uma tabela que armazenava datas em três colunas, uma para o ano, outra para o mês e a última para o dia. E a cereja do bolo é que todas elas eram do tipo char.[/quote]

Concordo.

Já vi umas tabelas aliens tambem, para armazenar dados temporários ,do tipo:

variável1 : varchar
variável2 : varchar
variável3 : varchar
variável4 : varchar
variável5 : varchar
variável6 : numeric
variável7 : numeric
variável8 : numeric
variável9 : numeric
variável10 : numeric
...
...etc

meio dinossauro.

#10

Lucas Emanuel,
Estavo me referindo na mudança de frameworks ou linguagem de programação, afinal, as regras de negócio do projeto já estão implementadas, logo, o esforço seria mínimo (em tesi). Fiz o exemplo de um projeto em GWT para JSF para explicar uma possível mudança. Ou seja os desenvolvedores não precisariam saber muito sobre as regras de negócio somente fazer as chamadas as packages.
Essa guerra entre DBAs e Desenvolvedores me parece antiga, algum DBA tem informações para acrescentar, ou link que fale sobre o assunto?

#11

[quote=fabioEM]Lucas Emanuel,
Estavo me referindo na mudança de frameworks ou linguagem de programação, afinal, as regras de negócio do projeto já estão implementadas, logo, o esforço seria mínimo (em tesi). Fiz o exemplo de um projeto em GWT para JSF para explicar uma possível mudança. Ou seja os desenvolvedores não precisariam saber muito sobre as regras de negócio somente fazer as chamadas as packages.
Essa guerra entre DBAs e Desenvolvedores me parece antiga, algum DBA tem informações para acrescentar, ou link que fale sobre o assunto?
[/quote]

Entendi agora.

Mas se voce desenhar bem a sua aplicação, a mudança de “GWT para JSF” como voce colocou no exemplo, ficaria independete da implantação da regra de nogocio, concorda?

Quanto aos links,

Aqui tem uma discussão legal: http://stackoverflow.com/questions/119540/business-logic-database-or-application-layer

#12

Regra de negócio é um risco totalmente desnecessário hoje em dia. Essa mentalidade vem dos dinossauros que programavam há 10 anos atrás ou mais dessa forma. Você fica totalmente preso ao fornecedor e as vezes nem pode migrar a versão pra não quebrar a compatibilidade. Essa conversa de ser OO ou evitar o Single Vendor Lock In parece algo que soa muito teórico, mas pode até salvar uma empresa. Trabalhei uma vez numa empresa que colocava várias regras de negócio no banco de dados, principalmente quando tinha relatório envolvido. Os sistemas eram velozes, tudo lindo e maravilhoso. Até que um dia o principal cliente disse que queria o sistema rodando em Oracle ao invés do PostgreSQL. O que aconteceu? Nunca conseguiram fazer essa migração e acabaram falindo…

#13