Concordo com a resposta dos colegas, mas gostaria de colocar uma questão adicional.
Se você trabalhar com bancos de dados pequenos, as colocações anteriores se encaixam perfeitamente. No entanto, com bancos de dados realmente grandes, a situação muda. Particularmente em ambientes de alta concorrência. O que acontece é que escalar horizontalmente um banco de dados dá muito mais trabalho do que escalar um servidor de aplicação. Se você tiver muitas regras de negócio no seu banco de dados, vai concentrar uma parte maior do processamento no servidor de banco de dados e menos no servidor de aplicação. Quando você acaba de implantar um sistema novo, está tudo tranquilo. Quando o tamanho da base e o número de usuários crescer, você vai precisar escalar esse banco de dados. E se a sua regra de negócio está concentrada no banco de dados, isso vai acontecer bem mais cedo do que o normal. O resultado é ter que trabalhar com replicação, cluster, particionamento e outras coisas relativamente complexas. Claro que em alguns casos colocar a regra de negócio no banco de dados ajuda. Para validações complexas, operações em lote e rotinas que exigem uma segurança maior no acesso aos dados, fazer tudo em PL dentro do bancos ajuda muito. Muito mesmo. Mas se você exagerar, pode ficar com um gargalo de CPU que vai lhe custar muito caro. Muito caro mesmo. Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos <arcano...@gmail.com> escreveu: > Bom dia pessoal, feliz 2018 a todos. > > Sou novo na lista e meu perfil é de desenvolvedor (para entenderem o > porque da minha pergunta abaixo... tentando justificá-la 🙄) > > Estou na faixa de conhecimento que vai do básico para intermediário em > relação a banco de dados e me interesso mais pela perfil técnico de banco > de dados do que da modelagem/administração de dados. > > Por isso, gostaria de bater um papo, ler o que vocês sabem ou acham sobre > casos, se já viram algum, em que foi-se construída uma aplicação que tinha > toda sua inteligência no banco de dados, podendo facilitar a desacoplagem > da camada do cliente de forma menos trabalhosa e associando a outras > tecnologias desta camada conforme a necessidade. > > Já viram algo do tipo? Recomendam tal abordagem? > > Por exemplo, hoje uma aplicação WEB, você desenvolve a camada > cliente(browser: html/css/js), desenvolve o backend (apache/nginx/tomcat - > php/python/java) e ainda mais específico, a camada do banco de dados. > > A idéia é continuar desenvolvendo a camanda cliente (porque não há como > fugir dela no casa da plataforma web), mas minimizar o possível a camada do > server, deixando-a apenas para o repasse de dados para o banco e a chamada > de procedures e functions no mesmo, onde realmente existirá o processamento > total dos dados, as regras de negócio etc > > Na experiência de vocês, já viram algo? Já tentaram algo do tipo? > > O que acham desta abordagem? > > Chamei-a no título de "orientado a banco de dados" com aspas porque > realmente não sabia como titular de outra forma menos redundante, ou com > pleonasmo, não sei. > > Espero poder muito aprender com vocês, independente do que eu expus aqui > ser viável ou não. > > Abraço a todos. > > > Samuel > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Fábio Telles Rodriguez blog: http:// <http://www.midstorm.org/~telles/>s <http://tellesr.wordpress.com/>avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
