Eu tento definir esse problema com a seguinte frase "quanto maior a distancia entre o dado e a regra de negócio maior a possibilidade de interferencia e consequente falha".
Admito que no passado me empolguei tanto com o desenvolvimento utilizando stored procedures que acabei fazendo experiencias e desenvolvendo e testando um postgresql application server para um poker game, um sistema de replicação master slave em pl/pgsql, um meta stored procedures(procedures que geram procedures) para substituição de um modelo (eca) EAV e a exposição transparente de stored procedures atraves de um package php chamado pl2Method. Dito isso: PostgreSQL é capaz de realizar todas essas ideias, mas... 1) tomar a decisão de implementar dessa maneira é um risco que a maioria dos tomadores de decisão não esta afim de encarar. 2) toda vez que um desenvolvedor diz "o banco deve ser usado somente como repositório" morre um elefante bebe na savana africana.(estão quase extintos) 3) os desenvolvedores de software tratam a persistencia como pura e simplesmente infra estrutura e isso foi maximizado por serviços como RDS e etc. Eles ajudam a olhar o sgdb como uma peça intercambiavel cuja escolha não deve ser levada muito a serio afinal "a gente só guarda os dados lá". 4) Concorrencia não é um problema natural para e-commerce e web development afins. e outros tantos pormenores. Enfim, eu sou a favor do uso de stored procedures(principalmente no postgresql, pelos motivos que elenco aqui https://ivonascimento.wordpress.com/2011/05/01/stored-procedure-e-interessante-para-uma-aplicacao/) mas creio q é inviavel enquanto problema cultural(como foi bem destacado pelo Leandro). A grande questão aqui é que esse assunto é ciclico e faço votos para que a onda atual baseada em (https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes) faça os desenvolvedores olharem novamente para essa questão. desculpem se fui prolixo... é que o assunto é empolgante. On 1/15/16 12:05 PM, Leandro Guimarães Faria Corcete DUTRA wrote: > Le 14 janvier 2016 18:25:05 GMT-02:00, Saraiva Silva > <matheus.sara...@gmail.com> a écrit : >> 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. > > Infelizmente, unanimidade entre desenvolvedores não quer dizer praticamente > nada, a não ser popularidade, dadas as deficiências culturais e de formação > na Informática. > > Temos de olhar os fundamentos. O único livro que já vi abordar isso do ponto > de vista conceitual foi _What, not how_, do Chris(topher) J Date. > > Resumindo: todos os argumentos para manter as regras de negócio são > circunstanciais, decorrentes ou da cultura de determinadas pessoas ou > organizações (tipicamente a síndrome do não-foi-inventado-aqui) ou do estado > de determinado ferramental: deficiências em SGBDs ou preferências por > determinado ambiente de programação. > > Por outro lado, só no SGBD as regras podem ser implementadas (1) obrigatória > e coerentemente, independente de eventuais defeitos ou mudanças em programas > aplicativos; (2) eficientemente, com mínima latência e com o planejador > escolhendo o melhor caminho de execução de acordo com o estado do sistema e > dos dados; (3) sem duplicação de esforços; (3) declarativamente, de acordo > com o modelo de dados. > > Isso dito, ainda há as tais circunstâncias, que podem forçar uma escolha > não-ideal por manter as regras fora da base de dados. Mas muitas dessas > circunstâncias não passam do uso de um SGBD ruim, que não tenha a riqueza de > linguagens e ferramentas de desenvolvimento do PostgreSQL, ou ignorância > desses recursos que o PostgreSQL oferece. > > Neste sentido, faz falta concorrência. Nenhum SGBD tem o ferramental de > linguagens de programação e riqueza lógica do SQL que o PostgreSQL tem, e > isso até mesmo faz com que muitos decidam não usar esses recursos em nome de > certa portabilidade, que eu creio ilusória. E muitos sistemas tornam-se > muito piores do que poderiam por isso, usando apenas uma espécie de mínimo > denominador comum, que nem sequer é realmente comum, do SQL e PLs. > > > _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
