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.
