"orientado a banco de dados"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

"orientado a banco de dados"

Samuel Teixeira Santos
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
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

ivo nascimento
Usar o postgreSQL como application server é possivel.
Os problemas gerais seriam a briga com o time de dev (a pratica de logica no DB é abominada pela maioria, tipo 99%), o versionamento da applicacao (stored procedures, tipos, domains...)

O que o postgresql vai te oferecer: stored procedures trusted(acessam o escopo do DB, e untrusted(acessam recursos externos [aqui esta a sacada])

as procedural languages do postgresql permitem que o conhecimento de programacao seja portado de outras linguagens para o contexto do db.

pl-python, pl-java, pl-sh, pl-php.... pl-pgsql, pl-sql

enfim. Não é dificil fazer, mas é dificil certo. É possivel. Se é recomendavel é discutivel. O termo é application server. Existem muitas threads sobre o tema:

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



--
Ivo Nascimento - Iann
-------------------------------------------------
   http://about.me/ivonascimento 
-------------------------------------------------

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Tiago José Adami
In reply to this post by Samuel Teixeira Santos
Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos
<[hidden email]> 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
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Samuel Teixeira Santos
​Fala Ivo e Tiago, tudo bom?

Valeu pela dica, agora não esqueço mais o termo "application server" que é exatamente o que o conjunto apache + linguagem representa mesmo: o servidor de aplicação. nem me toquei para pesquisar dessa maneira.

Muito bom o link da discussão da lista do postgres que você passou Ivo.

Deu para notar na discussão deles, que os que utilizam essa solução, vêem o estudo de design da utilização do Postgres como um servidor de aplicação como o ponto de entrada para fazer funcionar.

E, por sinal, eu já havia me deparado com a solução servidor nginx + extensão ngx_postgres implementada pelo pessoal do OpenResty que um dos usuários cita.

Uma pena que eles(OpenResty) não recomendam mais o uso desta extensão e sim de outra que usa a linguagem Lua com uma interface própria para acesso ao Postgres.

Vi na lista de discussão deles também que uma das desvantagens que eles vêem no uso da extensão acima é não pode fazer transações.

Contudo acho que isso seria facilmente resolvido, fazendo transações apenas nas procedures/functions. A extensão serviria apenas para calls.

Outro também citou o libpq, mas esta opção está muito desatualizada.

E só com o que você falou Tiago, já acredito que era suficiente para fazer qualquer um, que queira ver considerar opções, considerar o Postgres como servidor de aplicação.

Vou continuar buscando informações a respeito e se eu achar algo legal, posto para vocês.

Abraço e obrigado pelas respostas até então.

Samuel

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Alessandro Lima
>>Os problemas gerais seriam a briga com o time de dev (a pratica de logica no DB é abominada pela maioria, tipo 99%)
Realmente a maioria dos desenvolvedores é contra, mas faço parte do 1%
Prefiro toda regra de negócio no banco de dados, priorizando a performance
Utilizando o servidor de aplicação (java/scala/python) apenas como "bypass", realizando apenas a autenticação.

Alessandro Lima

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
l
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

l
2018-01-03 14:34 GMT-02:00 Alessandro Lima <[hidden email]>:
> Realmente a maioria dos desenvolvedores é contra, mas faço parte do 1%
> Prefiro toda regra de negócio no banco de dados, priorizando a performance

Na verdade, mais do que desempenho, a principal vantagem é a
consistência de dados.  Ainda mais quando se tem o cuidado de manter o
máximo de restrições de integridade no modelo de dados,
preferencialmente declarativamente mas alternativamente na forma de
restrições de verificação (CHECK CONSTRAINTs).  Em grande parte, as
(significativas) vantagens de desempenho decorrem da consistência de
dados ocorrer no próprio SGBD.


--
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:[hidden email]
+55 (61) 9302 2691        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=[hidden email]
_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Samuel Teixeira Santos
Bom dia!


Muito bom este retorno de vocês.

Uma curiosidade para quem já viu ​na prática: já que utiliza-se de check constraints, então a validação, geralmente, feita no cliente não é mais necessária?

Obrigado mais uma vez pela ajuda pessoal.


Samuel

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Samuel Teixeira Santos
Também achei este artigo bem interessante e compartilho com vocês



_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

ivo nascimento
In reply to this post by Samuel Teixeira Santos
Validacao em uma ponta nao torna desnecessaria a validacao em outra ponta. todo input precisa ser validado.



Em 4 de janeiro de 2018 08:57, Samuel Teixeira Santos <[hidden email]> escreveu:
Bom dia!


Muito bom este retorno de vocês.

Uma curiosidade para quem já viu ​na prática: já que utiliza-se de check constraints, então a validação, geralmente, feita no cliente não é mais necessária?

Obrigado mais uma vez pela ajuda pessoal.


Samuel

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



--
Ivo Nascimento - Iann
-------------------------------------------------
   http://about.me/ivonascimento 
-------------------------------------------------

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Samuel Teixeira Santos
Sim, tem de ser validado, mas pergunto exatamente se não basta validar em uma camada?

Porque um dado no formulário do cliente, a principio, poderia ter a mesma validação no banco.

Assim, não poderia ser feita apenas no banco?

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Fábio Telles Rodriguez
In reply to this post by Samuel Teixeira Santos
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 <[hidden email]> 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
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



--
Atenciosamente,
Fábio Telles Rodriguez
blog: http://savepoint.blog.br
e-mail / gtalk / MSN: [hidden email]
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

ivo nascimento
In reply to this post by Samuel Teixeira Santos
A validacao de um dado no input é para garantir que durante o flow do software ele esteja integro.
Se o flow do seu software for input->processamento->persistencia, então se voce nao validar o input, o processamento sera feito com dados sem garantia de integridade.
Se o flow for input->persistencia->processamento, então a persistencia com as constrains acabaria interrompendo o flow em caso de falha.
Porem, dizer que input->persistencia->processamento existe na pratica, seria uma mentira. A não ser que o input seja feito direto no db sempre havera um software agindo no minimo como pipe entre o input e a persistencia.


Em 4 de janeiro de 2018 09:23, Samuel Teixeira Santos <[hidden email]> escreveu:
Sim, tem de ser validado, mas pergunto exatamente se não basta validar em uma camada?

Porque um dado no formulário do cliente, a principio, poderia ter a mesma validação no banco.

Assim, não poderia ser feita apenas no banco?

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



--
Ivo Nascimento - Iann
-------------------------------------------------
   http://about.me/ivonascimento 
-------------------------------------------------

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Samuel Teixeira Santos
Fábio,

E, pode parecer contraditório, mas se houvesse uma instância intermediária do próprio SGBD, espelhando a estrutura do banco de dados, mas sem dados, onde pudesse ficar as PLs e esta instância se comunicasse com o BD via dblink? https://www.postgresql.org/docs/9.5/static/dblink.html

Vejam, só estou querendo levantar exatamente o que vocês já estão me mostrando, os prós, os contras, as dificuldades sobre o tema em discussão.

Então seria algo assim: Cliente(html/css/js - simples, sem validação) --> App Server( PostGRES - com estrutura do(s) banco(s), sem dados, mas com as PLs e checks) --dblink--> DB Server (Dados, constraints, checks, triggers)

Entendem que minha "simplificação" é minimizar o conjunto de tecnologias envolvidas para que minimize naturalmente a complexidade do todo?

Ou seja, eu reconheço hoje que o banco de dados é o principal, o dado é o mais importante, uma modelagem bem feita previne vários erros e mantém a integridade do dado.

Acontece que as tecnologias para chegar na etapa da persistência estão com uma gama de complexidade cada vez mais crescente. 

Quando penso que vão simplificar, parecem complicar ainda mais.

E concordo com o que falam, a ferramenta certa para um determinado problema. 

Eu só desejo simplificar o que eu considero um excesso de ferramentas e usá-las nos seus respectivos cenários. 

Claro, novamente tomem meus comentários, como de um iniciante em banco de dados, pois podem ver que minha linha de raciocínio ainda é mais em termos de desenvolvimento/programação.


e Ivo,

Quando você cita input->persistencia->processamento, você quer dizer persistência por estar no ambiente de execução do PostGRES? 

Algo como input->processamento&persistencia?

Porque ainda não fiz nenhum teste sobre estas idéias...

Mas depois do input, ainda penso que haverá o processamento (mesmo no SGBD) e que caso haja falha, ele me retornará um notificação informando da falha e neste caso não executaria a fase final que é persistencia.

No fim, confesso que ainda não peguei a idéia que você quis me explicar...

Valeu gente!

Abraço

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Flávio Alves Granato-3
On 04-01-2018 10:21, Samuel Teixeira Santos wrote:
> Então seria algo assim: Cliente(html/css/js - simples, sem validação)
> --> App Server( PostGRES - com estrutura do(s) banco(s), sem dados,
> mas com as PLs e checks) --dblink--> DB Server (Dados, constraints,
> checks, triggers)
Como validar uma foreign key? Se for no último server(Db Server) não
existe motivo para ter o primeiro server (App Server)

Sua solução é muito mais complicada que somente a famosa arquitetura de
duas camadas...

Aceita as sugestões assim:

- Se a aplicação for pequena: Siga/Estude/Considere/Analise as
orientações do Leandro e os outros
- Se a aplicação for grande: Siga/Estude/Considere/Analise as
orientações do Telles e os outros

* Também sou desenvolvedor e estou nesta lista há mais de 10 anos, já
passei por estas discussões várias e várias vezes aqui... tanto que
desta vez nem vou me pronunciar com opinião... :-)
Hoje tenho um barramento de serviços que temos que manter a latência de
acessos a ele abaixo de 100ms, conseguimos ficar em 48ms e estamos
caminhando para 5ms ou menos com aplicações reativas, entenda que
consideramos todas as opções mas é difícil conseguir recurso no
orçamento da empresa onde o foco da empresa não é TI, mas varejo...
então jogamos conforme a música.

Tenta prever até onde sua aplicação vai chegar e escolher a melhor
arquitetura para a demanda futura, talvez não seja o caso de começar com
ela. Seja qual for a sua escolha nunca dispense dados integros e
consistentes.
_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
l
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

l
In reply to this post by Fábio Telles Rodriguez
Le jeudi 04 janvier 2018 à 09:35 -0200, Fábio Telles Rodriguez a
écrit :

> …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.

Perdoem a ampla citação do Teles, mas é que tenho de lidar com vários
pontos dela.

        Vejam que o pressuposto acima é que o gargalo será CPU de PLs
(PL/PgSQL, PL/Python, PL/Java, PL/PSM &c).

        Entretanto, quando falei de colocar as regras na base tentei
deixar claro não ser essa a idéia.

        O ideal seria ter o máximo de regras de negócio
declarativamente, na forma de restrições de integridade (tipos,
chaves…); se não der declarativamente, na forma de restrições de
verificação (CHECK CONSTRAINT); só em último caso recorrer-se-ia a
procedimentos armazenados, que esses sim carregam uma penalidade de CPU
significativa.

        O que costuma acontecer é um modelo de dados acochambrado que
atrapalha o uso de restrições de integridade; o modelo em si é
ineficiente, e os procedimentos armazenados também.  Mesmo assim, para
situações normais (escalas razoáveis, boa manutenção), ainda costuma
sair mais eficiente que um servidor de aplicações separado, gerando E/S
adicional com latência, por ter de validar informações na base antes de
efetivá-las.  Além de que, estando na forma de restrições de
integridade, não haverá a possibilidade de programas ou usuários
contornarem o servidor de aplicações e introduzindo inconsistências na
base.

        Aproveitando, quanto a ter de validar dados na entrada:
geralmente é bem mais econômico para o cliente enviar os dados à base e
lidar com eventuais exceções de restrições de integridade que validar
no cliente, pelos mesmo motivos supracitados, relativos a servidores de
aplicações.

        O que realmente pode obrigar uma validação na camada de
apresentação é quando há latência significativa entre ela e a base.
Uma solução interessante era a do finado Dataphor: ele automaticamente
replicava as validações da base (no caso, um SGBD virtual, mas a idéia
era logo ter se tornado um SGBD completo, o que não ocorreu) para a
camada de apresentação, evitando inconsistências entre validações no
cliente e as restrições de integridade na base.


--
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:[hidden email]
+55 (61) 9302 2691        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=[hidden email]
_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
l
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

l
In reply to this post by ivo nascimento
Le jeudi 04 janvier 2018 à 09:35 -0200, ivo nascimento a écrit :
> A validacao de um dado no input é para garantir que durante o flow do
> software ele esteja integro.

Sinceramente não entendi.  O cliente ou programa começa uma transação;
ela só se efetiva se passar pelas restrições de integridade da base.
Simples.  ¿Ou perdi algo?


--
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:[hidden email]
+55 (61) 9302 2691        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=[hidden email]
_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Alexsander Rosa
In reply to this post by Samuel Teixeira Santos
Nosso ERP tem 385 stored procedures, a maior delas atende o WMS e roda na madrugada, gerando automaticamente centenas de pedidos no CD que serão depois separados e expedidos para as filiais (nosso maior cliente tem 20 delas). Temos várias outras que fazem tarefas complexas como "Importar XML", que recebe o XML de uma NFe do fornecedor e cria os registros nas diversas tabelas relevantes, incluindo no contas a pagar.

Uma grande vantagem é poder chamar as procedures por diversos aplicativos, desde clientes desktop (versões antigas do ERP), REST API + aplicações web / PWA (versão nova do ERP e WMS novo) e aplicativos console que rodam via SSH (WMS versão antiga).

Controlamos o versionamento via GIT usando um shell script: https://github.com/rednaxelbr/scripts
O script "gera_pgfunc" gera um arquivo "nome-da-procedure.sql" para cada SP usando a pg_get_functiondef() do PostgreSQL.



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



--
Atenciosamente,
Alexsander da Rosa


_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Reply | Threaded
Open this post in threaded view
|

Re: "orientado a banco de dados"

Samuel Teixeira Santos
​Fala pessoal.

Obrigado pelos relatos e sugestões.

Creio que aqui no trabalho também pode ser mais um caso de uso do postgres como application server. Traria mais benefícios, eu acredito.

Mas o importante é que posso repassar os prós e contras que cada um de vocês listou aqui e ver se os meus colegas também se interessam em usar.

Obrigado outra vez.

Abraço a todos

Samuel

_______________________________________________
pgbr-geral mailing list
[hidden email]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral