Regras de negócio no banco de dados

What is classpath? Membro desde: 26/10/2006 17:57:01 Mensagens: 7 Offline

Estou participando de um processo de customização de um ERP onde praticamente toda regra de negócio é feita no SQL Server. Qual a opinião de vocês sobre isso? Além disso, gostaria de outra opinião. O uso de udf's e views é util? Por que a empresa que desenvolveu o ERP adora stored procedures. Cada processo é feito dentro de uma única stored procedure monstro, umas com até 3 mil linhas. Eles alegam que usar udf's e views apenas deixaria o processo mais lento. Agradeço aqueles que deixarem suas opiniões.

HelloWorld Membro desde: 28/07/2007 14:16:47 Mensagens: 10 Offline

Ola !! Eu trabalho com pl/sql (oracle) em uma emprsa de medicamentos ,todas as regras de negócio são utilizadas trigger,procedures,view`s,functions ,package.Não vejo problemas e serem tratadas estas regras diretamente no banco ,pois são muitas transações todos os dias e é necessário otimizar ao maximo. Acho que a performance seria muito melhor se eles separacem as regras do que ter de ler 3000 linhas ou mais ,a questão das view`s é lógico que seria mais rápido a consulta dos dados necessários ,já que a consulta não irá percorrer toda a tabela e tambem ,retringiria os usuários não autorizados a não poderem visualizar os campos que não os competem. Acho que seria melhor repensar na reorganização destas regras ,pois certamente elas irão tomar uma dimensão maior futuramente e qualquer pessoa que prescisar efetuar a manutenção tera uma certa dificuldade. O ideal seria avaliar uma segunda opnião de outra consultoria.
Até mais...

Regra de negócios no banco de dados hoje em dia é inaceitável. A unica coisa pra mim que justifica uma stored procedure por exemplo seria um mega relatório. E mesmo assim eu tentaria entender com meu cliente o porque daquele relatório e apresentar uma solução melhor pra ele, fornecendo o mesmo resultado ou melhor.

HelloWorld Membro desde: 28/07/2007 14:16:47 Mensagens: 10 Offline

Acho que inaceitável não seria um bom termo visto que a todo momento é lançado um framework
para mapeamento objeto-relacional e outras técnicas de para maximizar performances. Quando se tem um software relativamente pequeno concordo em
manter as regras pelo próprio software,mas quando se tem relatórios que deve trazer muitos de dados seria bom repensar nesta caso,
pois o que torna o software lento é o processo de quantas vezes ele tem que buscar estes valores no banco de dados .E já no caso anterior ele está utilizando uma metodologia que preza este tipo de organização.
ATT FLAVIO.KENSHIN

Se um relatório traz muitos dados, estes não serão avaliados pelo usuário com certeza ( exceto casos especiais ), então um relatório longo não acredito que possa ser usado como justificativa.

Salvo casos especiais de performance crítica, hoje em dia não acho viável regras em banco de dados, dificulta depuração, e fica mais difícil encontrar uma falha logica. ( fora que seu sistema fica totalmente dependente do fornecedor de banco de dados )

flavio.kenshin wrote: Acho que inaceitável não seria um bom termo visto que a todo momento é lançado um framework
para mapeamento objeto-relacional e outras técnicas de para maximizar performances

Não entendi o que isso tem a ver com regra de negócios no banco. Poderia explicar?

flavio.kenshin wrote:Quando se tem um software relativamente pequeno concordo em
manter as regras pelo próprio software

O que você chama de software relativamente pequeno!? São justamente os softwares mais complexos que se beneficiam da utilização correta de OO.

flavio.kenshin wrote:quando se tem relatórios que deve trazer muitos de dados seria bom repensar nesta caso

Com relação a relatórios já dei a resposta no post anterior.

Temos aqui é um choque de forças. ( Entre os dois lados da força huehue)..

Pessoal, quem programa só em Java naturalmente nunca iria defender que as regras de negócio ficassem no banco! Temos por ai toneladas de aplicações que tem suas regras de negócio em stored-procedures, exemplos são os sistemas desenvolvidos em Oracle Forms/Reports, Power Builder e por ai vai.

E os principais argumentos do povão são:

-StoreProcedures são mais rápidas.
-É mais produtivo.
-Posso mudar de linguagem e mantenha todas as minhas regras de negocio.

Convencer que essa prática não é uma boa prática é dificil. essa cultura não vai mudar da noite pro dia. Na verdade ele é tão enraizada que tenho medo que nós sejamos convecidos a adota-lá.

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3368 Offline

"

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

Oi,

Eu acho que uma das situações que justifica o uso é quando o seu sistema tem que acessar uma DB na qual você não é o DBA

Neste caso o mais lógico e seguro seria você pedir para quem é o dono criar uma Stored Procedure que retorna o que você precisa e apenas chamá-la no programa

Abs

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Emerson Macedo wrote: Regra de negócios no banco de dados hoje em dia é inaceitável.

Eu acho radicalismo inaceitável.

This message was edited 1 time. Last update was at 08/09/2008 13:01:45

Alessandro Lazarotti wrote:

Emerson Macedo wrote: Regra de negócios no banco de dados hoje em dia é inaceitável.

Eu acho radicalismo inaceitável.

Se você ler o resto da minha mensagem verá o caso onde acho justificavel. Caso tenha algum outro exemplo onde seja aceitável, por favor coloque aqui no forum. Tenho certeza que agregará bem mais do que um simples "Eu acho radicalismo inaceitável".

PS: Não dê quote pela metade pra distorcer a mensagem, ok?

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Emerson Macedo wrote:Se você ler o resto da minha mensagem verá o caso onde acho justificavel. Caso tenha algum outro exemplo onde seja aceitável, por favor coloque aqui no forum. Tenho certeza que agregará bem mais do que um simples "Eu acho radicalismo inaceitável".

PS: Não dê quote pela metade pra distorcer a mensagem, ok?

... não vi onde distorci alguma coisa. Quotei uma frase até seu ponto final... mas deixa pra lá:

Emerson Macedo wrote:Regra de negócios no banco de dados hoje em dia é inaceitável. A unica coisa pra mim que justifica uma stored procedure por exemplo seria um mega relatório. E mesmo assim eu tentaria entender com meu cliente o porque daquele relatório e apresentar uma solução melhor pra ele, fornecendo o mesmo resultado ou melhor.

Ainda acho que radicalismo é inaceitável, principalmente ao definir critérios para uma arquitetura. Pra mim afirmar que não deve se aceitar determinada tecnologia que oferece recursos que podem lhe resolver um problema levantado pelo cliente, não tem fundamento.

Não é só "mega relatórios" que se beneficiam da performance de processos rodando em banco de dados. Todo e qualquer processo que utilize de grandes consultas associadas a regras, como queries em dados desustruturados de BI (que não é simplesmente relatórios), que tem por requisito não ultrapassar a barreira de "x" tempos... ou ainda triggers de bancos legados que iniciam localmente dados para uma nova base em real-time podem se valer de recursos particulares de cada banco.

É aquela velha história da ferramenta certa para cada caso, sem pensar em arquitetura de caixinha (isso ja virou frase de parachoque de caminhão)... do tipo "dessa água não beberei".

Se Stored Procedure satifaz certo requisito que outro método não satisfaz, utilize...

Alessandro Lazarotti wrote:

Emerson Macedo wrote:Se você ler o resto da minha mensagem verá o caso onde acho justificavel. Caso tenha algum outro exemplo onde seja aceitável, por favor coloque aqui no forum. Tenho certeza que agregará bem mais do que um simples "Eu acho radicalismo inaceitável".

PS: Não dê quote pela metade pra distorcer a mensagem, ok?

... não vi onde distorci alguma coisa. Quotei uma frase até seu ponto final... mas deixa pra lá:

Cortou sim, mas como você bem disse, deixemos pra lá ...

Alessandro Lazarotti wrote:

Emerson Macedo wrote:Regra de negócios no banco de dados hoje em dia é inaceitável. A unica coisa pra mim que justifica uma stored procedure por exemplo seria um mega relatório. E mesmo assim eu tentaria entender com meu cliente o porque daquele relatório e apresentar uma solução melhor pra ele, fornecendo o mesmo resultado ou melhor.

Ainda acho que radicalismo é inaceitável, principalmente ao definir critérios para uma arquitetura. Pra mim afirmar que não deve se aceitar determinada tecnologia que oferece recursos que podem lhe resolver um problema levantado pelo cliente, não tem fundamento.

Já foi dito anteriormente em que casos onde a performance para busca dos dados em grande quantidade é extremamente crítica, é valido, não entendi o ponto.

Alessandro Lazarotti wrote:
Não é só "mega relatórios" que se beneficiam da performance de processos rodando em banco de dados. Todo e qualquer processo que utilize de grandes consultas associadas a regras, como queries em dados desustruturados de BI (que não é simplesmente relatórios), que tem por requisito não ultrapassar a barreira de "x" tempos... ou ainda triggers de bancos legados que iniciam localmente dados para uma nova base em real-time podem se valer de recursos particulares de cada banco.

Se você parasse um pouquinho para entender o que eu escrevi, perceberia que quando se fala em "mega relatório" pode-se entender por "um acesso ao banco que necessida de grande quantidade de dados de forma trabalhada". Você está se apegando a palavra usada para distorcer mais uma vez. Volto a dizer: Sem requisitos de acesso a dados com volumes gigantes, como eu disse desde o primeiro post, o local mais indicado para se colocar as regras de negócio nos dias de hoje são nos objetos da sua aplicação.

Alessandro Lazarotti wrote:
É aquela velha história da ferramenta certa para cada caso, sem pensar em arquitetura de caixinha (isso ja virou frase de parachoque de caminhão)... do tipo "dessa água não beberei".

Se Stored Procedure satifaz certo requisito que outro método não satisfaz, utilize...

Acho que você está esquecendo que isso é um forum de Arquitetura de Sistemas onde tentamos discutir as melhores práticas da atualidade. Quando o colega falou que está desenvolvendo um sistema de ERP, pelo que pude perceber, não pareceu que existia um requisito desse tipo. Pelo contrário, ele reclamou que as stored procedures eram um monstro (segundo nosso amigo: até 3 mil linhas), e isso estava ferrando com o trabalho dele. Ninguém disse "dessa água não beberei", ninguém está propondo arquitetura de caixinha. Estamos falando de melhores práticas para os dias de hoje. Se é da sua época, já se foi o tempo onde professor de faculdade ensinada que regra de negócios se poe no banco (Se bem que ainda deve ter alguns que ensinam isso). É disso que estamos falando. Nada disso tem a ver com engessar aqruitetura.

É lamentável você perder seu tempo (e o meu) distorcendo um post para criar um flame sem necessidade.

rjun wrote:Estou participando de um processo de customização de um ERP onde praticamente toda regra de negócio é feita no SQL Server. Qual a opinião de vocês sobre isso? Além disso, gostaria de outra opinião. O uso de udf's e views é util? Por que a empresa que desenvolveu o ERP adora stored procedures. Cada processo é feito dentro de uma única stored procedure monstro, umas com até 3 mil linhas. Eles alegam que usar udf's e views apenas deixaria o processo mais lento. Agradeço aqueles que deixarem suas opiniões.

Qual o custo de dar manutenção nessas regras?

This message was edited 1 time. Last update was at 08/09/2008 17:23:31

Emerosn macedo wrote: Já foi dito anteriormente em que casos onde a performance para busca dos dados em grande quantidade é extremamente crítica, é valido, não entendi o ponto.

E eu não entendi oq você não entendeu.

Emerson, não comentei sobre o post inicial, mas fiz sobre o seu comentário, isso é natural em um fórum. Eu li o que você escreveu e não achei coerente, por isso submeti minha resposta.

Isso é mesmo um fórum de discussão sobre arquitetura, logo é normal que idéias expressas (ou mal expressas) aqui possam ser debatidas. Não entendo sua revolta. Se você acha que é flame discordar de algo que você diz ou tentou dizer, paciência.

[]'s

Emerson Macedo wrote: É lamentável você perder seu tempo (e o meu) distorcendo um post para criar um flame sem necessidade.

PS: Eu não perco meu tempo em fórum. Se posto, é pq achei relevante. Pelo menos essa é minha postura.
Quanto ao tempo que vc perder, eu não posso fazer nada.

Notícias, artigos e o maior fórum brasileiro sobre Java