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.
Olá, Samuel. Esta abordagem existe principalmente em sistemas fechados que requisitam alto nível de segurança e integração entre diversos clientes (agentes/softwares e interfaces). Um exemplo que posso citar - e com os quais trabalhei - são sistemas bancários. Quando trabalhei como analista/programador para o extinto HSBC Brasil há mais de 10 anos, praticamente todos os aplicativos continham somente a interface, todas as regras de negócio estavam em stored procedures e funções dentro de bancos de dados Oracle e Sybase. Existem várias questões a serem consideradas ao utilizar todas as regras de negócio no banco da dados. É preciso elencar os _pros_ e _contras_ de tal implementação. Algumas que posso citar: Pros: - Maior desempenho; - Possibilidade de compartilhar regras de negócio sem a necessidade de um servidor de aplicações; - Menor complexidade com todas as regras centralizadas (um pouco subjetivo); - Maior integração com recursos do banco de dados (travas/locks de registros, cursores, etc.); - Segurança, pois o banco de dados _deve_ ser uma _caixa fechada_ com pouco acesso; Contras: - Se você pretende usar mais de um _vendor_ ou produto (PostgreSQL, Oracle, DB2, etc.), reutilizará pouco código entre os diferentes bancos de dados; - Requer mão de obra qualificada para programar no banco de dados, até certo ponto escassa, haja vista que há muitos programadores Java/Python/.Net/RoR/etc. e poucos que conhecem realmente SQL e as PL dos SGBDRs; - As atualizações de regras de negócio _geralmente_ demandam um downtime maior e que afeta todos os usuários, diferente da atualização de servidores de aplicação distribuídos; - Se o banco de dados fica no cliente (customer), todas as regras de negócio ficam visíveis, então se você pretende fechar seu código 100%, esta não seria uma boa opção; - É mais difícil convencer Gerentes de Projeto e patrocinadores porque há um argumento _falho_ de que pode ser preciso trocar o SGBD no futuro, mantendo independencia de tecnologia, o que quase nunca acontece (por minha experiência); Elencar pros e contras é um pouco subjetivo. Eu sou fã desta abordagem por já ter visto que funciona muito bem. Mas você irá encontrar mil e um argumentos favoráveis e desfavoráveis a ela conforme a experiência de cada um. Tiago J. Adami http://www.powerdba.com.br _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
