Re: "orientado a banco de dados"

Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos
<[email protected]> 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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral