Ouvindo Opiniões

Novamente um tema que cada um tem um ponto de vista, alguns defendem até o fim as regras no banco, outros na aplicação e alguns no servidor de aplicação (multi-camadas).

Eu particularmente ainda não tive a oportunidade de trabalhar com multicamadas em projetos, apenas para fins didáticos, por isso não vou opinar sobre este método, mas sei que é um dos métodos que possui mais vantagens no que diz respeito a balanceamento de carga, já que você pode dividir módulos em diversos servidores.

Falarei um pouco da minha experiência com regras na aplicação e no banco de dados. Até um tempo atrás eu sempre programava as regras de negócio na aplicação, pois tinha medo de colocar tudo no banco por diversas razões: segurança, o código poderia ficar disponível para qualquer um ver, "dores de cabeça" se pensar em trocar de banco, limitação na linguagem PSQL entre outros aspectos.

Mas meu ponto de vista mudou bastante, depois que comecei a "brincar" com regras no banco percebi muitas vantagens, inclusive sem querer fazer um marketing :), essa foi uma das razões que me motivou a fazer o segundo módulo da Vídeo-aula de ClientDataSet com DBExpress e Firebird, na qual eu foco todo curso no banco ensinando a criar Storeds Procedures, Triggers e Views.

A grande vantagem que vejo em colocar regras no banco é a economia de tráfego que você ganha em muitos casos. Por exemplo, imagine que você tenha de varrer uma tabela, analisar cada registro e decidir que tipo de update deseja fazer. Se você programar isso na aplicação, terá que trazer todos registros pela rede e depois enviar N comandos de updates para o servidor, e tudo isso você estará gerando tráfego. Fazendo o código no banco, tudo é processado "localmente", os dados estão ali, portanto, nada passa pela rede, a não ser o resultado final que a Stored Procedure poderá retornar.

Outra grande vantagem é você poder centralizar e compartilhar estas regras com outras aplicações, pois bastará chamar as Storeds Procedures, seja a partir de uma aplicação Win32, Web, Delphi, C#, etc.

Claro que quando falamos em programar no banco, estamos falando ao mesmo tempo de investir em hardware, pois tudo será processado numa única máquina. Além disso, é necessário pensar muito na segurança criando senhas no banco com permissões restritas, senão você colocará em risco todo seu projeto, pois qualquer um poderia entrar no banco e modificar as regras de negócio.

Para “quebrar o gelo”, acho que a única desvantagem que vejo em programar no banco é caso queira trocar de banco ou se a aplicação precisar se adaptar a vários SGDBs, neste caso é muito trabalhoso reescrever as regras, pois cada SGDB possui uma sintaxe de codificação diferente.

Deixando esta desvantagem de lado, de qualquer forma não descarto de forma alguma a "técnica" de usar regras de negócio na aplicação, acho quase impossível tudo estar no banco, uma coisa ou outra sempre será melhor estar na aplicação.

Portanto, sempre gosto de mesclar com regras na aplicação e no banco de dados, quem sabe um dia eu não invista a sério em multicamadas e tenha outro ponto de vista!