2012/9/12 Flávio Alves Granato <flavio.gran...@gmail.com>: > > Mas para mim,
A frase veio truncada… >>> Vale lembrar que hoje >>> SGDB já considerando LEGADO advento do NoSql. >> O que mostra que o autor é uma toupeira no que se refere a dados, além >> de não saber escrever. > 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… >> 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… > 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. _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
