Em 25 de outubro de 2011 10:05, Flávio Alves Granato <[email protected]> escreveu: > Bom dia senhores, > > Sei que este assunto é muito espinhento mas não estou defendendo nenhuma > das visões sobre este assunto, apesar de ser desenvolvedor e puxar a > sardinha para o meu lado. Mas eu gostaria de saber dos senhores como tem > sido o dia a dia na implementação das regras de negócio de uma > aplicação, tem sido implementado no SGBD ou na aplicação? Na visão de > vocês, DBAs, quais os ganhos financeiro, desempenho, manutenabilidade e > outros com este tipo de abordagem?
IMHO, o ponto forte está no equilíbrio. Existem muitos modelos prontos para construir grandes aplicações e existem "design patterns" de monte ai fora como referência. Mas no fundo você precisa de profissionais poliglotas que possam ter uma caixa de ferramentas na bagagem com técnicas e soluções criativas para resoluções de problemas. O sucesso de qualquer modelo adotado dependerá do quão profundo é o conhecimento de sua equipe a respeito do modelo em si, pois isto será uma fonte de experiência para a equipe saber medir o quanto de código responsável por regras de negocio ficam na camada de aplicação e o quanto fica na camada de banco, alias gosto da definição de que sistema é composto por aplicação+banco. A escalabilidade é um desafio em cenários descentralizados como este, mas não impossível, pois quando você tem em mãos um PostgreSQL você não tem apenas um _Gerenciador de banco de dados_, você tem uma _Plataforma de desenvolvimento completa_, e isto permite estendê-lo das mais diversas maneiras, vide exemplos como pl/proxy, ou algum SQL/MED como dbilink ou foreign data wrappers. Mas escalabilidade é um desafio em qualquer situação. Muitos tem o equivoco de achar que um framework X ou Y vai escalar para eles, mas a real é que eles não escalam, quem tem que escalar é a sua aplicação, e se você precisa de escalabilidade tem que pensar o desenvolvimento focando nisto! No final das contas, parece que falamos e falamos sem dizer nada, mas a receita pronta em si não existe, no entanto o resumo da ópera pode ser uma divisão de seu "problemão" em problemas menores, impondo um limite para isto. A solução destes problemas pode estar parte no banco e parte na aplicação, o importante é que as interfaces desta "API" de comunicação entre ambos estejam claras, bem documentadas, cobertas por testes. De nada adianta você colocar todas as regras de negócio somente na aplicação ou somente no banco por questões de "manutenibilidade" ou "centralização" se seu código não for limpo, claro, bem escrito e fizer o que espera-se que ele faça. Lembre-se que é possível escrever em FORTRAN em qualquer linguagem. []s -- Dickson S. Guedes mail/xmpp: [email protected] - skype: guediz http://guedesoft.net - http://www.postgresql.org.br _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
