Re: [pgbr-geral] "orientado a banco de dados"

2018-01-07 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-05 Por tôpico Alexsander Rosa 
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 
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,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico Leandro Guimarães Faria Corcete DUTRA 
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:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico Leandro Guimarães Faria Corcete DUTRA 
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:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico Flávio Alves Granato 

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico ivo nascimento 
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 
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
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Ivo Nascimento - Iann
-
   http://about.me/ivonascimento
-
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico Fábio Telles Rodriguez 
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 
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:// s
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

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico ivo nascimento 
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 
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
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Ivo Nascimento - Iann
-
   http://about.me/ivonascimento
-
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico Samuel Teixeira Santos 
Também achei este artigo bem interessante e compartilho com vocês

http://renesd.blogspot.com.br/2017/02/is-postgresql-good-enough.html
​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-04 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-03 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2018-01-03 14:34 GMT-02:00 Alessandro Lima :
> 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:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-03 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-03 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-03 Por tôpico Tiago José Adami 
Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos
 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

Re: [pgbr-geral] "orientado a banco de dados"

2018-01-03 Por tôpico 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:

https://www.postgresql.org/message-id/CAN2Y%3DuPjF14F5A9JXj02_vaPw4TMR0WGQid_w80xt4sC8o4qGg%40mail.gmail.com
é uma duvida recorrente inclusive :)



Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos 
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
>



-- 
Ivo Nascimento - Iann
-
   http://about.me/ivonascimento
-
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] "orientado a banco de dados"

2018-01-03 Por tôpico 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral