>> Boa noite a todos, >> >> Estou chegando agora na discussão, mas posso falar sobre o tema, afinal >> criamos um ERP desta maneira, quem quiser pode conferir nos links abaixo. >> >> O que posso dizer é que no nosso caso foi a escolha mais certa que já >> fizemos, você precisa ter muito cuidado com a documentação, >> principalmente se o número de desenvolvedores for grande. >> >> Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente >> piloto posso te dizer ficou acima do esperado. >> >> Até hoje não tive problema de performance, o desenvolvimento é >> extremamente rápido, sem falar na questão da segurança e confiança nas >> transações! >> >> Na época lembro que muita gente falava que era loucura fazer desse >> jeito, e pelo que vi tem vários colegas da lista que pensam assim, o que >> posso dizer é que gostaria de ter enlouquecido bem antes, na época que >> segui o tal modelo 3 camadas e queria que minha aplicação fosse multi >> banco! >> >> Bom é só a minha humilde opinião, se precisar de alguma dica fique a >> vontade para perguntar, apesar do foco do seu sistema ser diferente acho >> que é a mesma idéia! > > Eu concordo. Mas tudo é uma questão de escala. > Utilizar funções para calcular em lote a folha de pagamento de 10 mil > funcionários é uma benção. Utilizar funções para todo e qualquer > processamento num ERP com centenas de transações ATIVAS, pode ser uma dor de > cabeça. > Veja que isso já foi pior em versões anteriores do Postgres, hoje já é > possível ajustar melhor a performance de funções e rastrear as estatísticas > destas, mas ainda dá mais trabalho. Queria saber a opinião de quem usa > pl/proxy em relação a isso, uma vez que você tem de encapsular tudo em > funções... > +2 cents.
Meus dois centavos nesta discussão vão na direção contrária. Suporto um sistema *lotado* de pl/pgsql com praticamente todas as regras de negócio dentro do banco de dados. - A idéia é ótima no seguinte sentido: tudo o que está fora do banco é só apresentação. - A idéia é péssima no sentido contrário: a aplicação tem centenas de milhares de usuários e funciona em escala nacional. Como toda a regra de negócio está no banco, o consumo de CPU é altíssimo, batendo em 100% em máquinas bastante parrudas. Quando é necessário aumentar a escala de atendimento, é necessário colocar máquina mais poderosa. Isso depois de muito tuning e uso de PostgreSQL 9 onde a parte de BI e relatórios com consultas mais complicadas são feitas em servidor hot-standby. Para escalar horizontalmente esse ambiente, só há uma forma: modificar toda a estrutura do banco quando estiver disponível totalmente a implementação de SQL-MED, pra poder fazer com mais facilidade o uso de dados remotos e separar fisicamente tabelas por regiões ou estados. Se a regra de negócio estivesse na camada de aplicação, seria possível dividir dados usando alguma técnica de sharding com mais facilidade e menos alterações em código. Minha dica para novos sistemas é sempre assim: - regra de negócio sempre numa camada fora do banco de dados; - llinguagens procedurais devem e podem ser utilizadas, mas de forma restrita para as funcionalidades de banco de dados (ex.: particionamento, regras para suprir restrições, validação de dados não possíveis por restrições, etc); - camada de apresentação separada da camada de aplicação. Assim suprem-se as técnicas MVC modernas e ganha-se em portabilidade (fica mais fácil migrar de SGBD ou misturar SGBDs) e escalabilidade (usar linguagem procedural para movimentar dados de forma independente da aplicação). []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
