Em 14/01/2016 18:25, "Saraiva Silva" <matheus.sara...@gmail.com> escreveu: > > Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e é quase unanimidade entre desenvolvedores a contrariedade em deixar as regras de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito. >
Minha opinião como DBA e Dev: Prós: - ganhos de desempenho em procedimentos complexos; - centralização das regras, disponível para qualquer aplicação em qualquer tecnologia (desde que possua drivers de conexão ao banco); - possibilidade de controle de acesso por usuário do SGBD; - atualizações são mais rápidas (basta atualizar via script); - o aplicativo será apenas um front-end, mais leve e mais rápido; Contras: - você precisará de no mínimo dois dois bancos para fazer testes regressivos e ser produtivo; - em procedimentos longos é mais difícil (mas não impossível) obter o retorno na aplicação sobre o status de execução (ex: "11% concluído"). - falta de mão de obra qualificada; - se a aplicação tem o requisito de usar mais que um SGBD (aplicativos que ficam hospedados no cliente ou por conta dele, SAP, TOTVS, CISS, por exemplo), torna-se uma dor de cabeça manter a mesma funcionalidade em linguagens de banco diferentes: Pl/PgSQL, T-SQL, SQL/PL, etc.; - se no meio da regra é necessário consultar um agente ou recurso externo, tipo web service, outro banco de dados, um arquivo em disco, etc., a complexidade aumenta muito, talvez fique impossível; - muito mais difícil fazer debug; Minha opinião pessoal é que tudo o que seja crítico em desempenho rode no banco. O resto depende de muitos fatores e precisa ser discutido em equipe. Tiago J. Adami
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
