Quando eu sai do MS Access e descobri o Interbase (pai do Firebird), fiquei maravilhado com os recursos, principalmente triggers e stored procedures. Percebi que com isso eu conseguiria transportar grande parte da lógica do meu aplicativo para o servidor, liberando a estação de algumas tarefas e deixando o aplicativo mais simples.
Minhas aplicações são Cliente-Servidor 2 camadas apenas, então meu relato aqui é baseado nesse tipo de aplicativo.
Então passei a criar SPs indiscriminadamente para qualquer “operaçãozinha” que não teria ganho nenhum usando SP. Não sei porque, mas eu pensava: “Ah, mas se a lógica dessa operação mudar, eu não precisarei recompilar o aplicativo, apenas alterar a SP no banco! Que beleza! Todos os meus problemas acabaram!”.
Hoje eu penso nisso e dou risada. Essa idéia se mostrou totalmente errada. É muito mais simples eu alterar o aplicativo, gerar um novo release e enviar para o cliente do que modificar a estrutura do BD dele. Lógico que alterar a estrutura de forma automatizada é possível, mas mesmo assim, você esbarra numa série de probleminhas muito mais chatos do que simplesmente substituir o aplicativo pela nova versão. Muitas vezes você não consegue modificar a estrutura com usuários logados, ai seu cliente tem que tirar todo mundo do sistema. Em grandes empresas isso pode ser bem complicado. Além disso, acontece com frequência de você não conseguir modificar a estrutura mesmo quando todos os usuários sairam do sistema, então você tem que reiniciar o serviço do BD, e por ai vai.
Outro detalhe é que se você usar uma boa orientação a objetos no seu aplicativo, a tendência é deixar todas as regras de negócio nos seus objetos de negócio e não no BD, afinal é pra isso que os objetos servem. Perceberá que o banco de dados vai atuar como um simples meio de persistência dos dados, muitas vezes não utilizando nenhum dos seus principais recursos como triggers, integridade referencial, etc. É muito comum ver BDs de aplicativos orientados a objeto com nenhum relacionamento entre as tabelas, nem nada.
Outra vantagem de colocar pouca lógica no BD, é que você acaba ficando menos dependente do banco de dados. Não que você consiga ficar totalmente independente, mas isso certamente ajudará.
Lógico que em muitas situações, a melhor coisa é tirar proveito do poder do banco. Eu tenho muitos relatórios processados inteiramente em SPs, controle de estoque gerenciado por triggers (muito bom), etc. O ideal é saber dosar a quantidade certa de um e de outro.
Porém, existem casos que deixar o máximo de lógica no banco é a melhor solução.
Estou trabalhando em um aplicativo bem interessante para a plataforma PalmOS. O aplicativo vai rodar em equipamentos Tungsten C, acessando banco de dados Firebird via Wi-Fi. O meu aplicativo PalmOS é apenas uma das interfaces de acesso ao sistema do cliente, cuja interface principal é toda web e foi criada por outra empresa. Este sistema já está rodando no cliente e nós temos que estudar como ele funciona para desenvolvermos o módulo PalmOS. Existem várias regras, algumas bem complexas, que nós não precisamos nem ter conhecimento se elas estiverem programadas no banco.
Por exemplo, se o cliente compra acima do seu limite, o pedido entra na fila de aprovação por um gerente. O módulo Palm não precisa saber disso, basta ele inserir o pedido. Neste momento um trigger é disparado, consulta o limite do cliente, o valor do pedido e seta o flag no pedido para ficar pendente de aprovação ou liberado. Essa é uma forma inteligente de centralizar a lógica no banco. Se a empresa que faz o sistema mudar a lógica de aprovação do pedido, eles nem precisam acionar a minha empresa para atualizar o módulo Palm.
A forma mais profissional de resolver isso seria ter uma camada intermediária acessada tanto pelo aplicativo web, como pelo aplicativo Palm, e a lógica ficaria somente neste aplicativo e teríamos uma solução multi-camadas. Mas isto não é possível, visto que o aplicativo web de retaguarda é duas camadas e já está pronto.
Se estivessemos falando de aplicativos desenvolvidos em .NET e o módulo portátil usando PocketPC (que suporta .NET Compact Framework), poderíamos compartilhar classes de negócio, o que poderia ser usado para evitar colocar muita lógica no BD, mas esse não é o caso.
TPodcast