[pgbr-geral] "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

[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 :)

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

[Tiago José Adami]

Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos

Post by 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.

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

[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 <https://github.com/openresty/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 <http://asmith.id.au/mod_libpq.html>, 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

[Alessandro Lima]

Post by ivo nascimento
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

[Guimarães Faria Corcete DUTRA, Leandro]

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.

[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

[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
​

[ivo nascimento]

Validacao em uma ponta nao torna desnecessaria a validacao em outra ponta.
todo input precisa ser validado.

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

[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?

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

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

[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

[Flávio Alves Granato]

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.

[Leandro Guimarães Faria Corcete DUTRA]

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?

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

Post by 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
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: ***@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br

[Leandro Guimarães Faria Corcete DUTRA]

Le jeudi 04 janvier 2018 à 09:35 -0200, Fábio Telles Rodriguez a

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

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

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

[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