Regras Dentro do Banco de Dados

Postado em Atualizado em

Já se passaram muitos anos desde a década de 90 e ainda assim eu continuo ouvindo e vendo muitas corporações colocando regra de negócio das soluções dentro de um banco de dados. Hoje o cenário de soluções corporativo é outro completamente mais complexo e a arquitetura em duas camadas não oferece características que sustente sua evolução. Resumidamente, soluções construídas em duas camadas não cumprem requisitos como escalabilidade, extensibilidade, manutenibilidade, segurança, perfomance e disponibilidade. Dessa forma, hoje usamos arquitetura n-camadas que é a única que, se bem projetada pode cumprir todos os requisitos não-funcionais característicos das soluções atuais. Segue um resumo básico dos velhos e já batido motivos documentados que justificam o não uso de regras dentro de um banco de dados:

1. Acoplamento

Regra dentro do banco de dados viola o princípio SOC que define que cada pedaço de um sistema precisa estar localizado em um lugar único e exclusivo promovendo isolamento, manutenção, reutilização e futura substituição, sem impacto nas outras partes.

2. Falta de Portabilidade

Regras escritas dentro do banco não oferecem portabilidade entre os diferentes produtos concorrentes da mesma filosofia de banco de dados adotado. Na década de 90 já era um transtorno e só tínhamos os famosos SGDB. Hoje então a coisa piorou com o surgimento com NoSQL e suas varias opções estruturais.

3. Código Inflexível

Regras no banco de dados são na maioria das vezes escritas usando store procedures que são desprovidos de recursos de OOP como encapsulamento, agregação, composição, associação, herança e polimorfismo e da mesma forma não conseguem usufruir de nenhum tipo de padrões (Patterns) arquiteturais, projetos e programação.

4. Know-How Especializado

Regras no banco de dados precisam ser manutenidas por profissionais que detenham conhecimento especializado para aquele particular produto e filosofia de banco de dados adotado, sendo difícil e ou caro de se encontrar mercado ou de se formar internamente.

5. Problemas de Performance

Soluções de grande porte, dotadas de um grande e crescente numero de acessos simultâneos e com a execução de regras pesadas vão degradando gradativamente a peformance da solução, podendo até (que é o acontece na maioria dos casos) derrubar o serviço, uma vez que os banco de dados são desprovidos de devidos gerenciamentos de recursos encontrados normalmente em MIDDLEWARE relacionados com técnicas de otimizações, tunning, comunicação assíncronas, mensageira (MOM), escalabilidade vertical e horizontal apropriadas aplicadas especificamente na execução das regras de negócios.

Gostaria de deixar claro que não existe verdade absoluta em nada. Esse assunto faz referencia a uma opção arquitetural como qualquer outra e que os responsáveis estão livres para fazer a sua própria tomada de decisão, desde que estejam cientes dos pros e contras. Eu acredito que muitas corporação sofrem atualmente com esse cenário por ter que manter e evoluir algum legado dessa época. O problema mesmo é começar hoje uma solução assim. O post fica aberto para comentários.

“Quão grande és tu, ó Soberano SENHOR! Não há ninguém como tu, nem há outro Deus além de ti, conforme tudo o que sabemos.” 2 Samuel 7:22

Anúncios

7 comentários em “Regras Dentro do Banco de Dados

    Adalto Jr. disse:
    23/07/2012 às 16:31

    Ótimo artigo!

    Concordo com sua visão, atualmente seguir esse tipo de solução é como dar um tiro no pé.. esse tipo de prática tem que ser abolida.

    rafaelzeffarafaek disse:
    23/07/2012 às 16:36

    tbm concordo. o dificil é convencer o DBA hehe

    Renato Lopes disse:
    24/07/2012 às 18:59

    A primeira vez que fiz usando stored procedure e trigger, achei o máximo, mas quando precisei dar manutenção…… queria refazer tudo de novo que seria mais facil… nunca mais regras dentro do banco, excelente post.

    Danilo disse:
    25/07/2012 às 15:14

    Olá Fernando, gostaria de parabenlizá-lo pelo artigo. Sempre é bom discutir prós e contras. Concordo com os “contras” com relação os processos de banco de dados, porém na empresa em que trabalho existem em torno de 100 máquinas contando as filiais e todo a regra de negócio é escrita em Procedures em Oracle.
    Vantagens: 1) Velocidade de processamento, pois os dados necessários pelo processo já estão no banco. 2) Tráfego de rede: o programa usuário ou o servidor de aplicativos não recebe dados do banco para serem processados. Isso geraria tráfego intenso na rede.
    Até hoje só recebemos elogios de auditores contábeis que chegam em nossa empresa e não precisam ficar esperando rodar grandes processos como por exemplo o Sped Fiscal. Pelo contrário todos reclamam que em outras empresas a demora é maior, creio eu que seja pelo fato das regras de negócio estarem implementadas no front-end. Aqui no interior de SP é muito comum as empresas usarem Genexus para criar aplicativos e utilizam o banco de dados apenas como repositório de dados, sem explorar todo o poder que ele pode oferecer.
    Na minha visão, levando em conta o AMBIENTE em que trabalho, que não depende da WEB, não consigo imaginar solução melhor do que colocar as regras de negócio embutidas no banco de dados devido à velocidade de processamento e à não necessidade do fator “barramento de rede” para trafegar resultados de consultas enormes para a máquina requisitante para o devido processamento.

    Gostaria de discutir este assunto com outros profissionais, pois o tópico é muito interessante.

    Fernando Franzini respondido:
    25/07/2012 às 15:57

    Vc esta com razão. Se os seus requisitos hoje são resolvidos por 2 camadas ok..Vc tem uma otima solução…

    Vale lembrar 3 coisas.
    1. requisitos mudam…
    2. negócios mudam..
    3. tecnologias mudam muitooooo!

    Sendo assim, o arquiteto é o “cara” que visa projetar uma solução unicamente visando “as mudanças”.Isso quer dizer que no produto final vc precisa ter mecanismos de mudanças com baixos impactos.

    Eu trabalho com empresas que tem soluções ha 15 anos. Nesse tempo, ela mudou de GUI DOS para Windows, depois para Web, depois para Web2 e agora estamos atendendo web mobile. Banco de dados eram texto, depois foram para SGDB e agora estamos no NoSQL. Muitas coisas aconteceram aqui não seria o caso de abrir essa discussão.

    Eu gostaria que vc pensasse assim comigo…Até quando sua solução vai ter apenas 100 maquinas? As corporações hoje, precisam estar na web para aumentar/facilitar seus negocios…por mais que seu caso seja extremo, uma hora chega a sua. E quando ela for para web? Na web pode ter milhões de acesso? E se tal coisa acontecer? E se seu sponsor cortar a verba do seu sgdb pago e ir quiser usar um free? ja aconteceu conosco kkkk. O problema é achar que isso nunca vai acontecer…até que o dia acontece.

    Sendo assim vc não pode olhar somente o HOJE…vc precisa olhar para amanha..a dor de cabeça dos arquitetos hoje é…..”E SE ACONTECER………”

    Gustavobit disse:
    22/05/2014 às 14:53

    E, então nosso colega Danilo começou a desenvolver o sistema e retirou as regras de negócios da base(rsrsrs).
    Brincadeiras fora a parte, meus parabéns pelo post e ao comentário do Danilo também, trazendo a tona um retorno interessante a ser abordado, pois ele utilizou um case.

    Já se passaram 2 anos do post. Terias mais alguma coisa para acrescentar em questão arquitetural?

    Fernando Franzini respondido:
    23/05/2014 às 11:22

    Para aqueles que gostam da idéia de procedure seguem a dica – https://fernandofranzini.wordpress.com/2014/04/25/groovy-procedure-groovedure/

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s