Boa parte defende o bom sendo e a distribuição de tarefas entre aplicação e o banco. O grande desafio é fazer isso usando frameworks ORMs, pois eles partem da ideia que o banco deve ser um mero repositório, nem se quer são capazes de manipular todos os tipos de dados que os SGDBs permitem. Eu particularmente acho que são forças opostas que se repelem, onde você tem que fazer uma escolha, ou você usa StoredProcedures para deixar no banco alguma lógica que fique melhor nele, como um inserts e updates complexo. Ou você abre mão dos recursos do banco e faz tudo na aplicação. A única maneira que eu vejo de fazer essa distribuição de tarefas de forma sensata deixando no banco o que fica melhor com ele e deixando na aplicação aquilo que ela pode fazer melhor, é não usando ORM e escrevendo os SQLs da aplicação na mão.
ORM e SPs não combinam. SPs destroem a ideia do ORM que é abstrair o SQL do programador. Em 15 de janeiro de 2016 17:17, Alan Tavares <[email protected]> escreveu: > > On 15-01-2016 14:19, iannsp wrote: >> >>> Eu não consigo enxergar beneficios em ser "multi database" a não ser >>> aumentar as possiblidades de venda, salvo casos em que esse é o papel do >>> software (orquestrar varias sgdb engines) >>> >> Não quer dizer que não exista. >> >>> O paradoxo esta em que, ao tentar se livrar de um acoplamento a um banco >>> de dados especifico durante o projeto para aumentar as vendas a equipe >>> acaba desenvolvendo mais código, logo, mais bug, logo, mais queijo com >>> menos queijo. >>> >> Imagino que nas procedures, modelagens e afins de sua bem feitoria não há >> mais queijos com menos queijo. >> >> > Boa tarde senhores vou contar um pouco da minha historia que isso explica > 100% meu ponto de vista. > > Bom eu sou um programador desenvolvi em varias linguagens, a maioria WEB > principalmente ASP clássico e PHP, quando comecei meu contato com banco de > dados era o básico criar tabelas tudo com varchar(50) e pronto, até que > entrei em uma empresa para trabalhar com ASP e SQL Server. Ali aprendi que > tudo o que eu fazia era um assassinato, entendi o porque de alguns > problemas de lentidão no passado já que nas empresas que trabalhei o "DBA" > era o próprio programador. > Nessa empresa aprendi a criar e trabalhar com store procedures, triggers > views e ai veio a primeira decepção com o MySQL, pois nessa empresa 90% da > regra do negocio estava no banco de dados. Sai da empresa e comecei a > trabalhar como freelancer, fiquei decepcionado com o MySQL pois queria > aplicar as coisas que havia aprendido nos meus outros projetos e não dava > pois o MySQL é muito limitado, já tinha ouvido falar do Postgres mas pra > falar a verdade não ouvi falarem muito bem (programadores) e convivi com > essa decepção. Até que a coisa apertou tive que largar o freela para algo > concreto e chegando na empresa que estou agora no primeiro dia conversando > com o outro programador, este reclamando da lentidão do sistema e que > queria migrar o sistema do MySQL para MongoDB pq viu artigos falando que > era mais rápido e tal, pedi para ver o banco de dados e tive um semi > infarto, na maior tabela do sistema que na época tinha 90 mil linhas já > encontrei o problema da lentidão tudo com varchar 50 qnd não 255 e sem > nenhuma chave nem no campo id, colocamos chave nos principais campos e o > sistema melhorou 50% os funcionários ate vieram na sala perguntar o que > havia acontecido pq o sistema estava rápido. Neste momento acabei virando > DBA aqui e ai surgiu um desafio teríamos que desenvolver um sistema para > analise de vendas e outros parâmetros o que iria gerar um processamento > muito alto foi então que vi que o Mysql não iria atender pois teria que > fazer muita coisa na aplicação, somos só 2 na equipe de TI o outro > desenvolvedor é louco para usar o MongoDB sou meio averso a NoSQL e mais o > chefe que entende um pouco de desenvolvimento, mas foi ai que resolvi > pesquisar sobre NoSQL mesmo sendo averso e achei uma palestra do Matheus de > Oliveira PostgreSQL e porque você não precisa de NoSQL > <http://www.infoq.com/br/presentations/postgresql-e-porque-voce-nao-precisa-de-nosql> > Minha vida mudou desde então, o PostgreSQL era tudo o que eu precisava, > pois poderia fazer o processamento dentro do Postgres evitando assim o vai > e vem de dados na aplicação. No inicio do desenvolvimento ficaram meio > seticos pois estava fazendo tudo no banco inclusive fazendo request numa > API. Quando finalizei surpresa geral, tudo rodando sem dar problema. > A aplicação esta rodando a 3 meses e a unica parada que teve foi por causa > da VM a aplicação processa uma media de 10 milhões de linhas por dia, não > possui muitos acessos simultâneos mas seria inviável ao meu ver fazer isso > fora do banco de dados. > É meio relativo quanto a regra de negócios estar no banco ou na aplicação, > mas eu particularmente como trabalho com web sou da seguinte opinião, > > - o cliente faz uma requisição via http para a aplicação > - a aplicação por sua vez tem que fazer apenas 1 acesso ao banco para > pegar os dados > - o banco retorna para aplicação que faz um tratamento nesses dados e > devolve para o browser > - no browser se possível ainda mando algo para ele processar como por > exemplo a somatória de valores > > assim distribuo a carga de trabalho com todo mundo pois se hj tenho 10 > acessos simultâneos amanha posso tem 100, 200, 1000 nunca se sabe então eu > penso dessa forma. > > Depois de toda essa vivencia uma coisa que me pergunto as vezes é porque > os NoSQL estão tão em alta hoje em dia, eu penso que isso de deve ao fato > que programador não sabe nada de SQL, modelagem e NoSQL não vc joga > qualquer coisa la que ta ok e um pouco da culpa disso também para mim vem > do fato que quase todos usam uma camada de abstração de dados. Mas fazer o > que o mundo esta cada vez mais "pratico" o bom é que quanto menos pessoas > souberem de banco mais trabalho nós teremos só ver o exemplo desses caras > que já estão aposentados e ainda trabalham com cobol Mainframe pq hj em dia > ninguém conhece. > > Acho o seguinte se o banco de dados tem todos esses recursos devemos > explorar o máximo agora para servir só de repositório os NoSQL estão ai pra > isso. > > Abraços > > Alan Costa > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
