Não Faça Regras de Negócio Dentro do SGDB

Postado em

240px-Stop_hand_nuvola.svgJá 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. Péssima Manutenção e Código Inflexível

Regras no banco de dados são na maioria das vezes escritas usando store procedures  (filosofia procedural da década de 60) que são desprovidos de recursos e as diretrizes da 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 performance 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.

6. Ausência de Recursos

Regras de negócio corporativas normalmente englobam o uso de recursos como logica binária, manipulação de arquivos PDF, DOC, XLS, XML, JSON.  Comunicação com sistemas externos como LDAP, SMTP, FTP, Mensageira, SOAP, REST etc. Os SGDB normalmente não possuem API’s disponíveis para estes fins e muitos outros recursos, salvo em casos raros que alguns provedores de SGDB fornece alguma coisa bem limitada e proprietária para tratar um ou outro. A coisa piora por que normalmente não existe abertura para se acrescentar uma API de terceiros para dentro do banco.

Conclusão

Martin Folwer no livro Patterns of Enterprise Application Architecture capitulo 8 escreveu:

“Por todas estas questões, muitas pessoas evitam implementar regras de negócio dentro de um banco de dados. Eu tento me alinhar com esta visão a menos que haja um grande ganho de desempenho a ser obtido, o que, para ser sincero frequentemente ocorre. Nesse caso, pego um método de negócio da camada de domínio e, alegremente  o transformo em um procedure dentro de um banco de dados. Faço isso apenas em áreas com claro problemas de desempenho, tratando-o como um abordagem de otimização e não como um principio arquitetural.”

Joshua Bloch no livro Java Effective capítulo escreveu no item 55 (que eu resumi):

“A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de profile e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.”

Acredito que todos estes fatos já fornecem base suficiente para que você tenha condições de fazer a sua tomada de decisão 😀 . Até a próxima!

“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

2 comentários em “Não Faça Regras de Negócio Dentro do SGDB

    […] o assunto das regras de negócio dentro do banco de dados, hoje eu gostaria de apresentar uma estrutura arquitetural que se tornou um design pattern muito […]

    […] Gostaria de aprender um pouco sobre arquitetura? Veja esse bate papo aqui: A Little Architecture. O assunto gira em torno de algo que eu postei anos atrás: Não Faça Regras Dentro do Banco de Dados. […]

Os comentários estão encerrados.