"orientado a banco de dados"
Locked
"orientado a banco de dados"
 
|
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 |
Re: "orientado a banco de dados"
|
|
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 <[hidden email]> escreveu:
-- Ivo Nascimento - Iann
------------------------------------------------- http://about.me/ivonascimento ------------------------------------------------- _______________________________________________ pgbr-geral mailing list [hidden email] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral |
Re: "orientado a banco de dados"
|
|
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 |
Re: "orientado a banco de dados"
|
|
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 |
Re: "orientado a banco de dados"
|
|
>>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 |
|
|
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 |
Re: "orientado a banco de dados"
|
|
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 |
Re: "orientado a banco de dados"
|
|
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 |
Re: "orientado a banco de dados"
|
|
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:
-- Ivo Nascimento - Iann
------------------------------------------------- http://about.me/ivonascimento ------------------------------------------------- _______________________________________________ pgbr-geral mailing list [hidden email] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral |
Re: "orientado a banco de dados"
|
|
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 |
Re: "orientado a banco de dados"
|
|
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.Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos <[hidden email]> escreveu:
-- Atenciosamente, Fábio Telles Rodriguez blog: http://savepoint.blog.bre-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 |
Re: "orientado a banco de dados"
|
|
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.Em 4 de janeiro de 2018 09:23, Samuel Teixeira Santos <[hidden email]> escreveu:
-- Ivo Nascimento - Iann
------------------------------------------------- http://about.me/ivonascimento ------------------------------------------------- _______________________________________________ pgbr-geral mailing list [hidden email] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral |
Re: "orientado a banco de dados"
|
|
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-> 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 |
Re: "orientado a banco de dados"
|
|
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 |
|
|
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 |
|
|
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 |
Re: "orientado a banco de dados"
|
|
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:
Atenciosamente,
Alexsander da Rosa _______________________________________________ pgbr-geral mailing list [hidden email] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral |
Re: "orientado a banco de dados"
|
|
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 |
«
Return to PostgreSQL - Brasil
|
1 view|%1 views
| Free forum by Nabble | Edit this page |