Inteligência em bancos de dados

Todo desenvolvedor que tenha um conhecimento razoável sobre banco de dados já passou pela dúvida sobre como lidar com a possibilidade de concentrar boa parte das regras de negócio dentro do banco de dados.

Atualmente, com a disponibilidade de várias linguagens de programação, isto se torna cada vez mais tentador: a Oracle possui além do consagrado PL/SQL, suporte a Java, o PostgreSQL chegou num estado de arte suportando uma infinidade de linguagens de programação dentro de seu SGDB e agora já faz um ano que o MySQL também possui sua própria implementação de linguagem procedural.

Mas o uso desgovernado deste tipo de expediente pode trazer algumas desvantagens. Longe de querer ditar melhores práticas, gostaria aqui de discutir um pouco este tema que tem me intrigado por algum tempo.

Nos primórdios da informática, onde reinavam solenes apenas os computadores de grande porte, não havia a opção de distribuir a carga de processamento em várias máquinas separadas. Os SGDBs relacionais também começaram a nascer somente no final da década de 70 com o DB2, Oracle e Ingres. Sendo assim, toda a aplicação se concentrava em geral na mesma máquina.

Com o surgimento dos microcomputadores veio a revolução da arquitetura cliente-servidor no final da década de 80. A idéia era criar aplicações rodando em microcomputadores (clientes) e armazenar as informações em SGDBs que ficassem em máquinas mais confiáveis (servidores). Com isso foi possível adquirir servidores com um preço bem mais acessível que os computadores de grande porte, uma vez que a carga de processamento da aplicação ficou distribuída nos microcomputadores dos usuários.

Nesta época, linguagens como o VB e o Delphi invadiram o mercado construindo aplicações cliente servidor com pães numa padaria. As aplicações cliente-servidor em boa parte foram muito bem sucedida, mas em ambientes corporativos elas começaram a apresentar uma performance muito insatisfatória. Conforme o tamanho do código cresce e as aplicações vão ficando mais pesadas várias coisas acontecem:

  • O código fica difícil de manter (bem, isto não é nenhuma novidade…)
  • Em transações longas, onde muito cálculo é utilizado, as máquinas utilizadas no cliente tem baixa capacidade de processamento, tornando a operação lenta.
  • Em transações longas com várias consultas ao banco de dados, o tráfego de rede é muito alto e gera um gargalo de desempenho.
  • Pequenas falhas na rede durante o processamento de transações longas podem no mínimo obrigar toda a operação a ser reiniciada.

É neste ponto em que entra em cena a linguagem procedural embutida no banco de dados. Com isso, é possível disparar gatilhos em circunstâncias determinadas e executar procedures e funções dentro do SGDB. O ganho de velocidade em aplicações cliente-servidor é realmente fantástico em transações longas.

Mas como tudo na vida , algumas pessoas se empolgaram! A idéia destas pessoas foi a de utilizar as aplicações no cliente apenas para exibir e receber informações, deixando todo o processamento das informações dentro do SGDB. Uma vantagem interessante desta técnica ocorre quando você possui mais de uma aplicação acessando o mesmo banco de dados. Um exemplo disto poderia ser uma aplicação cliente-servidor tradicional utilizada para alimentar e processar as informações, uma planilha extraindo informações complexas do banco de dados e uma aplicação web fazendo consultas de informações específicas. Neste ponto, centralizar toda a “inteligência” ou “regras de negócio” dentro do SGDB facilita a vida de quem tem que manter o código destas diferentes aplicações.

E qual a desvantagem disto? Bem, os ajustes de desempenho do SGDB tem que mudar drasticamente. Antes a coisa mais importante no desempenho de um banco de dados transacional era a velocidade dos seus discos. Com o acúmulo de tarefas de processamento da aplicação dentro do SGDB na mesma máquina o processador começa a assumir um papel cada vez mais importante. O resultado disto pode ser um SGDB muito lento.

Enquanto isto novas tendências de mercado começaram a ganhar força: Programação Orientada a Objeto e Aplicações Web. Na programação orientada a objeto, as linguagens procedurais perdem seu papel, pois estão muito mais próxima da lógica relacional dos SGDBs, embora o Sr. C. J. Date afirme que a maior parte dos fundamentos da P.O.O. estão na teoria relacional. Seja como for, outra tendência que ganhou força com a orientação a objetos é a programação em camadas. Com isso, o aplicativo começa a ser dividido em unidades funcionais, sendo que algumas delas certamente ficarão a cargo de servidores dedicados com maior capacidade de processamento, e conexão de rede dedicada com o SGDB. O mesmo acontece naturalmente em aplicações Web onde o processamento não é realizado em um computador cliente e sim no servidor web (ou em mais servidores se a aplicação for realizada em várias camadas).

Hoje se fala muito em camadas de abstração de bancos de dados e em frameworks MVC. Eles permitem que você desenvolva a aplicação sem se preocupar com qual banco de dados está utilizando. Desta forma, as linguagens procedurais nos SGDBs perderiam completamente sua função! A idéia é realmente tentadora.

No entanto, quando estudamos as boas opções no mercado, verifica-se a existência de brechas para enviar comandos específicos para cada SGDB. Isto ocorre porque se a abstração de SGDB fosse perfeita, certamente não precisaríamos de diferentes SGDBs no mercado. Há momentos em que é preciso acessar funcionalidades específicas de cada SGDB que as camadas de abstração não são capazes de lidar diretamente. Quando se precisa de funcionalidades avançadas e/ou alto desempenho em longas transações, as linguagem procedurais ainda são utilizadas mesmo em aplicações com várias camadas como no modelo MVC.

É claro que as camadas de abstração de dados tendem a evoluir, assim como o padrão SQL tem evoluído. No entanto estamos longe de uma padronização das linguagens procedurais dentro de bancos de dados, além de haverem novas funcionalidades sendo implementadas todos os dias nos SGDBs relacionais. Dito isto, é provável que aplicações continuem se beneficiando de camadas de abstração de dados, no entanto elas não cobrirão plenamente as necessidades de grandes aplicações corporativas, devendo haver sempre brechas para acessar diretamente as funcionalidades especificas de cada SGDB.

Enfim não existe uma regra clara para utilização de linguagens procedurais dem SGDBs. Existem funcionalidades como prover auditabilidade, gerar logs e realizar a carga de dados complexos onde estes são consagrados, além do processamento de longas transações com velocidade e confiabilidade ainda imbatíveis.

Em sistemas pequenos, a centralização da inteligência da aplicação dentro de SGDBs é aceitável, porém com o aumento de aplicações Web e frameworks como o Ruby On Rails, esta não parece ser uma tendência de longo prazo.

Por fim, este assunto é bastante polêmico e não existem regras formais para o uso de linguagens procedurais em SGDBs. A criatividade e o bom censo dos desenvolvedores e DBAs podem sempre apontar para novos rumos ou demonstrar equívocos.

Se você tem uma opinião diferente ou quer acrescentar alguma coisa, deixe seu comentário abaixo.

1 comentário

  1. anônimo Responder

    Cara, parabéns pelo texto e também pelo Blog, muito interessante!!

    abraço

  2. anônimo Responder

    Banco de Dados serve para guardar DADOS.Lugar de lógica (“inteligência”) é no Servidor de Aplicações.

  3. anônimo Responder

    E extremamente tentador concentrar nossas regras de negocios em um ambiente totalmente diferente do front-end
    Mas sinceramente acredito que colocar todas as regras no banco não sei se realemnte e a melhor opção ..
    Acho que a ideia de frameworks intermediario que trabalha com vários bancos ainda será a melhor solução.
    Trabalho em um ambiente que possui 3 SGDB funcionando e uma verdadeira salada de fruta e quando colocamos as funções nos bancos temos que criar 3 funções. pois nem tudo é compativel.
    De qualquer forma o texto está bem feito e nos faz pensar no que seria o ideal.
    Parabens pelo artigo.

  4. anônimo Responder

    Trabalhar com MVC vem se mostrando ser a melhor opção. Regras de Negócio em meio a dados e/ou aplicação só complicam a vida de quem mantém(e não somente desenvolve) sistemas.

    Fazer com que o raciocinio seja voltado não somente a rapidez da entrega do produto mas também a agilidade da manutenção de sistemas é essencial para casos de sucesso. Ainda mais quando lembramos que segundo o velho Pressman “50 a 70% do tempo gasto com software está na sua manutenção”.

    Ótimo texto(artigo?) está de parabéns… precisamos que esse tipo de idéia seja mais divigalda(até para nós mesmos começarmos a pensar duas vezes antes de não usar um padrão de camadas

    [] a todos

    ricardo ponto cardim em gmail ponto com

  5. Tony Silva Responder

    Parabéns, ótimo artigo para um assunto interessante e atual!

    Bom, pra mim a inteligência deve ficar na aplicação, que hoje é O.O. e cada vez mais baseada em frameworks.

    Mas a base de dados continua sendo relacional. Assim, a segurança e integridade dos dados devem ser REFORÇADAS pelos recursos disponívels no SGBDR em questão, como restrições (constraints), gatilhos (triggers), chaves alternativas, estrangeiras e que tais. Segurança tem seu preço.

    E em uma empresa dificilmente um sistema está isolado dos outros; nesse caso é preciso implementar uma via de acesso SEGURA aos dados da base. Os demais sistemas podem acessar tais dados via web services, pacotes de rotinas escritas no SGBDR (como uma membrana protetora que envolve os dados) ou outra estratégia definida pelo arquiteto da aplicação. Acesso direto aos dados, nunca! De novo, segurança tem seu preço.

    Isso pode mudar quando (e se) os atuais SGBDR forem substituídos por SGBDOOs.

    Mais uma vez, parabéns.

  6. Marcos Alves Responder

    Show de bola! Estou a muitos anos tendo esta conversa com colegas, e a minha posição é muito inclinada a ter o máximo de regra de negócio no banco de dados. Durante os anos, mais comprovei este posicionamento, quando ao precisar acertar regras que antes estavam na aplicação e hoje estão no banco, as fiz com agilidade e sem precisar compilar o sistema novamente, trocar versão, e o pior, atualizar o banco por completo, tendo em vista, que em cenários como o meu, onde programo para windows e o ERP é desenvolvido em delphi, precisamos trocar o executável geral em todas as máquinas, pois certamente sistema x bd estão compatível entre si.

    Sei que algumas situações, até mesmo para não encher o banco de porcaria, ficar no sistema é o melhor!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *