Em 12/09/2012 16:59, Guimarães Faria Corcete DUTRA, Leandro escreveu: >> >> Não tem necessidade dessa agressividade, como eu já disse em outro >> momento, vai existir de tudo sempre, até pessoas que acham que SGBD é >> legado... > Pois é, mas eu não suporto a ignorância posando de mestra… Terapia? hehehe... > > >>> Isso não é verdade há anos em PostgreSQL. Temos várias linguagem OO, >>> funcionais e até OO e funcionais. >> Alguém realmente usa? > E como! O David Fetter, por exemplo, fez muita coisa interessante em > PL/Perl. E tem PL/Java, PL/pgPSM para conformidade com os padrões, > PL/Scheme funcional… > > O que importa não é se há quem mais use. O que importa é se resolve > os problemas que alguém possa ter… > > >>> Outra inverdade. Vide, por exemplo, pg_pool e XC. >> Conhecimentos que estou adquirindo, mas em empresas que passei tem >> adotado escalar a aplicação e não o SGBD. > Esse é o ponto: conhecimento. As faculdades Java (no dizer o Joel > Spolski) não têm ajudado… Não senhor! As faculdades Java não ensinam nem Java quanto mais escalar aplicação... é o mercado mesmo que faz isso. E convenhamos é muito mais fácil hoje em homens/hora configurar uma aplicação para escalar do quê um SGBD, visto aqueles todos por menores que comentam na lista sobre XC, Cluster e affins... só para exemplo, dizer ao jboss que ele deve trabalhar em conjunto com outro jboss em outra máquina é questão de uma linha de configuração... > > >> Haha... uso ORM... tanto que é o motivo desta thread que abri... não >> criticar o não uso, mas saber quando é melhor o "não uso" e começo a >> entender, nem precisa enfatizar que o melhor uso de ORM é nunca, ou ao >> menos não por enquanto... > Por aí… embora o Teles tenha dito que o Hibernate andou melhorando, e > eu saiba que SQL Alchemy também não era tão ruim. > > >> Para meu entendimento, o que seria SGBD conter toda a lógica de >> negócios? Normalmente tenho feito de maneira que o SGBD confirme( check, >> constraints... ) as regras desenvolvidas na aplicação e não levando a >> aplicação a ser uma visão da base. > Nem tanto ao mar, nem tanto a terra… > > A aplicação não precisa ser apenas uma visão. Há muita coisa > importante no desenvolvimento de interface humana, fluxos de trabalho > &c. Mas as regras organizacionais (‘de negócio’) deveriam ficar o > mais perto da base possível, e de preferência declarativamente. O > Date tem até um livreto interessante a respeito, _What not How_. > > Há vários riscos conhecidos ao separar as regras da base. O mais > óbvio é a dificuldade de garantir que todo acesso à base aplique as > regras, o que costuma levar a dados inconsistentes e toda a dor de > cabeça e custos decorrentes. Joguemos com as regras de fato, do mercado, a onda é criar um usuário, um esquema e milhares de tabelas neste "banco de dados" e a aplicação cuidar do acesso. "Se" o ideal é ficar perto da base, é outros quinhentos, eu não concordo pelo fato que base de dados é feito para guardar dados e não regras ( não disse validar regras ). É onde os NoSQL deslumbram algumas pessoas e com razão, eles só querem que o banco grave e retorne os dados o mais rápido possível, se a base vai ficar inconsistente ou não e seus problemas, ai são mais quinhentos...
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
