Regras de negócio no banco de dados

Ola !! Eu trabalho com pl/sql (oracle) em uma emprsa de medicamentos ,todas as regras de negócio são utilizadas trigger,procedures,views,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 views é 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.

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:

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

flavio.kenshin:

Quando se tem um software relativamente pequeno concordo em
manter as regras pelo próprio software

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á.

"

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

Eu acho radicalismo 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?

“Emerson Macedo”:

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á:

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:

“Emerson Macedo”:

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á:

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. [/quote]
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:

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.

Alessandro Lazarotti:

É 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…

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

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

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

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.

E eu não entendi oq você não entendeu.
Não entendi o ponto pois você argumentou em cima de uma coisa que eu havia dito por não ter lido o que eu escrevi ou simplesmente ignorado.

Alessandro Lazarotti:

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

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.
De relevante não teve nada. Quanto ao meu tempo perdido, basta você responder o que for agregar alguma coisa ao invés de gerar uma flame só para chamar atenção. Isso é coisa de troll. Sinceramente não acredito que você seja esse tipo de pessoa.

Eu não lí, nem agora voltando, que você tenha dito onde a performance para busca dos dados em grande quantidade é extremamente crítica, é valido. Você citou um fim (relatório), mas não o meio (uma consulta). Consultas não servem apenas para fins de relatórios. Além disso, tbm coloquei que não é apenas para processos que envolvam grandes consultas mas tbm para alguns serviços de integração que estão, por exemplo em mesma base ou mesmo para atividades de BI.

Entendi perfeitamente o contexto da pergunta inicial, entendi sua colocação, contudo tenho a minha opinião. A qual já explanei.

“Emerson Macedo”:

De relevante não teve nada. Quanto ao meu tempo perdido, basta você responder o que for agregar alguma coisa ao invés de gerar uma flame só para chamar atenção. Isso é coisa de troll. Sinceramente não acredito que você seja esse tipo de pessoa.

Como disse, posto o que eu julgo relevante, assim como acho que você faz o mesmo, ou pelo menos deveria. Se o que “você ou eu” postar agrega ou não é muito relativo, tão quanto o que achamos que seria de relavância, portanto, vamos continuar no autruísmo. A questão da insinuação quanto a “flames”, “querer chamar atenção”, “trolls” vou simplesmente ignorar, pq isso sim, de nada agrega e foge de qualquer discussão que eu esteja disposto a participar em um fórum de tecnologia.

Enfim, peço sinceras desculpas por ter “quotado” seu post inicial, desconsidere, já que isso lhe incomodou tanto.

[]s

Também sou do time que não é tão inaceitável assim implementar regras de negócio no banco. Especialmente se eu estiver desenvolvendo sistemas que nunca usufruirão dos benefícios de manter as regras em um modelo do domínio, por exemplo. Pra falar a verdade, pra certos sistemas nem Java eu usaria.

Adicionando à lista de frases de caminhão: otimização prematura é a fonte de todo o mal ( putz, já virou lugar-comum :? )

Cara tem casos e casos.

Eu acho que nao vale a pena criar procedures com coisinhas pequenas que nao vao fazer nenhuma diferenca, por exemplo, quando eu trampava no Brasil comecaram a desenvolver um site em php/mysql, ai o cara que era “arquiteto” (que por sinal nao era nem formado em computacao) achou que era uma boa ideia criar procedures pra cada consulta no banco, mesmo aquelas mais estupidas tipo “select * from users where userID = ?”, procedure de 3 linhas, resultado o banco ficou com trocentas milhoes de procedures que nao faziam a menor diferenca de estar la ou nao.

Aqui onde eu trabalho, quando eu vi que tinha umas procedures no banco eu pensei “ihhhh fodeu” mas todas sao procedures se justificam, por exemplo, esses dias eu escrevi uma procedure que obtem itens em um site por exemplo um blog que foram mais votados, usando como base uma formula doida. O que eu fiz foi criar um funcao com essa formula, e criar uma procedure que pega dados de varias tabelas aplicando essa formula, ai me retornava somente os dados que eu realmente precisava.
Acredito que se eu fizesse isso sem procedure ia tomar muito tempo porque primeiro eu teria que buscar no banco todos os registros e aplicar a formula de calculo via programacao, totalmente inutil trazer todos os registros se o que me interessa sao somente 10 baseados em calculos.

Nesse caso eu acho que a procedure eh uma mao na roda.

//Daniel

peczenyj:

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

Na verdade, isso nem foi levantado como hipótese já que o sistema não é nosso. Estamos apenas adquirindo. Levantei essa questão por que eu particulamente acho estranho deixar tudo, eu disse tudo, no banco de dados. O aplicativo (feito em não sei qual linguagem, mas suspeito que Delphi) serve apenas como uma interface de operação para o usuário.

Alessandro, quero deixar claro que quotar o post é perfeitamente normal. Você pode procurar nas mensagens que respondi e verá que diversas respostas minhas foram quotadas e continuie a discussão sem problemas. O Ponto aqui foii dizer que eu fui radical, sendo que logo após a minha frase sobre “inaceitável”, deixei claro que existem exceções sobre o assunto. Isso me deixou chateado sim.

Confesso que me excedi por causa disso e que poderia ter me expressado melhor. Portanto, minhas desculpas pelo que eu disse sobre você.

[]s

rjun:

peczenyj:

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

Na verdade, isso nem foi levantado como hipótese já que o sistema não é nosso. Estamos apenas adquirindo. Levantei essa questão por que eu particulamente acho estranho deixar tudo, eu disse tudo, no banco de dados. O aplicativo (feito em não sei qual linguagem, mas suspeito que Delphi) serve apenas como uma interface de operação para o usuário.

"

marcosalex:

Emerson Macedo:

Isso foi muito encorajado nas faculdades tempos atrás e tem muita gente ainda hoje que acredita ser a melhor forma.

Pois é. Será que é porque na tecnologia da época tinha vantagem isso?

A performance é bem superior, em muitos casos a codificação é menor e a manutenção é mais simples. Mas se o cara quiser fazer cagada e criar stored procedures salsichas, é terrível!

Quanto a manutenção mais facil quando o código está nas procedures, minha opinião é diferente. Acredito que nos objetos a manutenção seja mais fácil.

Acho este tópico muito polêmico para pouca coisa !
Tenho uma visão bem simplista sobre o assunto, banco de dados serve pra guardar dados e ponto.

Já trabalhei em mais de um sistema que tinha as regras de negocio no banco, na teoria é maravilhoso mesmo, mas acho que só quem trabalhou com isso pode dizer de situações pitorescas que acontecem, por exemplo:

• Validar CPF/CNPJ, pô, ter que chamar o banco pra isso é besteira. (Você também tem opção de duplicar esta validação no cliente)
• Reaproveitar código ! Isto na teoria é legal, mas nunca vi algum lugar que reaproveitasse lógica de maneira decente. Tudo fica muito dependente de tabelas e tipos de dados … coisas que com OO ficam muito mais simples de resolver.
• Usar uma linguagem OO e ter regras no banco … os diferentes paradigmas não permitem ter um dominio de classes decente. No melhor dos casos, você consegue um modelo anêmico, ver detalhes aqui.
• Se amarrar a banco de dados. Num dos sistemas que trabalhei a lógica estava no banco, um Sql Server, ao vender o produto para uma grande instituição, eles “bateram o pé” e só aceitavam se usasse Oracle … e ai ? O sistema teve que ser praticamente refeito em PL/SQL, sem contar que o lado “cliente” da aplicação também teve que ser bastante alterarado, ou seja, FAIL!
• Comparado com as liguagens atuais, escalar banco de dados é um caos.

Resumindo, toda experiência que tive na área com aplicações com Regras de negócio no banco se resume a códigos que são obrigatoriamente remendados para usar termos/formas jurássicas de se programar em procedures.

Quem é obrigado a manter/desenvolver sistema já feito assim, tudo bem, faz parte, sinto pena de ti.
Agora começar um sistema do zero neste modelo, pra mim, é a maior roubada que alguém pode fazer.

Não sei se a melhor solução, mas sou a favor de modelar o dominio da aplicação numa linguagem de alto nivel (temos várias), se você não faz idéia de como, recomendo a leitura sobre Domain-Driven Design.

Flames com parcimônia, por favor.
Roger Leite

A implementação de DataBinding do Delphi não necessariamente encoraja a manutenção de regras de negócio no banco, até porque cada componente dispõe de dezenas de eventos para implementar essas regras na própria aplicação cliente. Na verdade, nesses cinco anos de programação em Delphi nunca vi nenhuma aplicação onde as regras de negócio estivessem totalmente no banco, boa parte dessas regras estavam mesmo na aplicação cliente.

Eu acho radicalismo inaceitável.

++

Se vc aloca desenvolvedores num cliente, e no contrato diz que é esse cliente que vai ditar arquitetura, padroes e etc… vira pra ele e fala
que vc nao vai fazer regra de negocio no banco pq objetos é melhor.

Ele tira vc e poe quem faça. E vc perde alguns belos zeros na sua conta por radicalismo.

Já trabalhei com empresa assim, fazer oq, fizemos sem questionar!

Eu acho radicalismo inaceitável.
É, ele quase não é radical…basta ver suas mensagens à respeito do EJB…

A implementação de DataBinding do Delphi não necessariamente encoraja a manutenção de regras de negócio no banco, até porque cada componente dispõe de dezenas de eventos para implementar essas regras na própria aplicação cliente. Na verdade, nesses cinco anos de programação em Delphi nunca vi nenhuma aplicação onde as regras de negócio estivessem totalmente no banco, boa parte dessas regras estavam mesmo na aplicação cliente.[/quote]
Bem, eu já vi muito.

fabiocsi:

Se vc aloca desenvolvedores num cliente, e no contrato diz que é esse cliente que vai ditar arquitetura, padroes e etc… vira pra ele e fala
que vc nao vai fazer regra de negocio no banco pq objetos é melhor.

Ele tira vc e poe quem faça. E vc perde alguns belos zeros na sua conta por radicalismo.

Bem, no caso dos EJBs eu sou. Não vi um sistema até hoje que tivesse a necessidade real de usar EJB. Nunca escutei de alguém um caso real em que EJB foi “a solução”. Sempre atrapalhou mais que ajudou. Mas em fim, sobre os EJBs basta dar uma procurada aqui mesmo no GUJ pra ver que eu não sou o único que diz isso. Na verdade acho que os demais já até se cansaram de ficar repetindo a mesma coisa por diversos tópicos.

Em todas elas você não viu nem 10% das regras no cliente? :shock:
Basta você ter um cálculo em um form ou em um datamodule… Voilá!

"

Em todas elas você não viu nem 10% das regras no cliente? :shock:
Basta você ter um cálculo em um form ou em um datamodule… Voilá!
Vi sim. Isso era mais um problema. Regra em 2 lugares…

marcosalex:

Passei por situações em que o código feito na procedure era 10% do código feito em Java e muito mais simples. Por isso julgo mais fácil a manutenção. Já vi situações de concorrência que tinha uma verdadeira ginástica em Java pra conseguir evitar incoerência do estoque de produtos com os estoques da loja. Foi substituído mais de 300 linhas de código por uma simples trigger de 5 linhas e funcionou com muito mais performance.

Bom, também já vi códigos que aconteceu exatamente o inverso, por isso não compensa generalizar.

• Como fazer testes automatizados em uma stored procedure?
• Da pra fazer um mock das tabelas pra testar de forma unitária?
• Carrega-se um banco vazio pra fazer testes?
• Cria-se uma procedure pra testar a outra?

Essas questões são interessantes, pois desenvolver sem testes automatizados atualmente não é considerado uma boa coisa.

"

marcosalex:

Emerson Macedo:

Quanto a manutenção mais facil quando o código está nas procedures, minha opinião é diferente. Acredito que nos objetos a manutenção seja mais fácil.

Passei por situações em que o código feito na procedure era 10% do código feito em Java e muito mais simples. Por isso julgo mais fácil a manutenção. Já vi situações de concorrência que tinha uma verdadeira ginástica em Java pra conseguir evitar incoerência do estoque de produtos com os estoques da loja. Foi substituído mais de 300 linhas de código por uma simples trigger de 5 linhas e funcionou com muito mais performance.

Bom, também já vi códigos que aconteceu exatamente o inverso, por isso não compensa generalizar.

Mas a maior desvantagem que vejo em deixar regras de negócio no banco é que não irão ficar todas as regras lá. Logo, você teria de dar manutenção em dois lugares, duas linguagens, duas plataformas,…

Em suma, se quiser o melhor dos dois mundos, você terá que trabalhar (balanceadamente) com ambos.

Então nós concordamos que existe um problema relacionado a testabilidade para esse tipo de abordagem, certo?

Sim, mas de qualquer forma você tem que testar se a constraint que você criou está correta. A pergunta é: Como fazer isso? Você teria que manualmente rodar a procedure pra ver. Isso seria um trabalho manual e meio chato, o que é bem contrário ao objetivo dos testes automatizados.

É obvio que a Oracle vai dizer que por questão de performance o melhor é que a regra de negocio esteja no banco e a Microsoft tambem segue o mesmo caminho, tambem é obvio que isto deixa a empresa refem do banco e isto eles não dizem.
Para um sistema pequeno da para engolir esta idéia, isto porque se no dia amanhã a empresa resolver adotar outro banco não será muito dificel migrar todas as regras, agora pense em sistema gigante integrado que contenha todas as regras no banco, como será para migrar para outro banco ?. Como Diretor / Gerente de TI é fundamental levantar esta questão porque tudo é função do orçamento que esta disponivel para comprar (licenças), manter (DBAs) este banco ou migrar para outro banco.
Sob o aspecto comercial, software para venda, o ideal é que as regras estejam em um framework para que o cliente possa escolher em qual base irá investir, se é que não comprou ainda. Tive clientes que me disseram: “tenho um servidor linux e quero uma base OpenSource!”, neste caso minha salvação era que meu aplicativo não era dependente da base.
Os grandes ERP levam em consideração o lado do cliente e tambem deixa a base a criterio do cliente quando este já não possue uma.

Esse Emerson Macedo é um idiota! E arrogante ainda por cima…

Quatro anos depois voce nos trouxe uma ótima contribuicao. Valeu, aprendi muito com seu post.

Ah, e so pra constar, eu concordo com boa parte do que o Emerson disse ha quatro anos.

Bom galera, com certeza é uma pessima pratica.

Mais tem uma variante que é o contexto, já aconteceu no inicio da carreira quando sabia menos do que sei hoje(rsrsrs) não tinha conhecimento tecnico suficiente e muito menos tempo para estudar uma solução descente e ter que resolver muitas coisas direto no banco. Sei lá acho que chicotear um desenvolvedor por algo que não foi bem feito é complicado.