2012/9/13 Flávio Alves Granato <flavio.gran...@gmail.com>: > Em 12/09/2012 16:59, Guimarães Faria Corcete DUTRA, Leandro escreveu: >> Pois é, mas eu não suporto a ignorância posando de mestra… > Terapia? hehehe...
Talvez fosse o caso. >> 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... Sendo que, por definição — por mais que a decadência tenha tornado a definição obsoleta —, faculdades deviam ensinar os conceitos de lógica, algoritmos, dados e programação funcional, não os charlatanismos de OO ou especificidades de escalar (para cima ou para baixo). > 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... Sim, mas é uma situação que muda a cada dia, com cada nova versão. Até porque o PostgreSQL é o primeiro SGBD livre sólido, e seu desenvolvimento tem se acelerado impressionantemente. Mas há um contraponto: essa facilidade é amiúde enganosa, porque acaba escondendo problemas que, quando aparecem, freqüentemente são catastróficos. Essa conta de homens/h acaba sendo pobre por não levar em conta que bons homens precisam de menos homens (e portanto horas) hoje, e geram menos necessidade de homens/h amanhã. > 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... A dor de cabeça é que a tendência ao longo do tempo de vida do sistema é que (1) regras declarativas são muito mais fáceis de manter e muito mais sólidas que as procedurais e (2) dificilmente todas as transações eternamente passarão por esse grupo de servidores de aplicação, o que tende a gerar as famigeradas inconsistências. São riscos a se administrar — ou evitar, quando possível. > eu não concordo pelo fato que base de dados é feito para > guardar dados e não regras ( não disse validar regras ) Pois é, mas se tu não concordas é que não conheces os conceitos por trás das ferramentas que usas. As restrições de integridade, como mostram o livro do Date e outros mais, e como mostra uma análise lógica, nada mais são que regras organizacionais declaradas sob outro nome. E é muito mais eficiente garanti‐las junto aos dados que num sistema separado, com toda a latência, o consumo de banda, mudanças de contexto envolvidos. O ‘x’ da questão é justamente a distribuição da carga, que costumava ser cara, até porque associada a produtos proprietários, e só agora está chegando ao mundo livre. > É 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... A história é uma velha senhora, sempre a murmurar… (Portugal). Ou, quem não conhece a história é condenado a repeti‐la. Codd criou o modelo relacional justamente pelos problemas criados pela falta de SGBDs lógicos. OO volta aos SGBDs baseados em grafos, e NoSQL vai pelo mesmo caminho… Por isso o povo babou no Prevayler. Para minha vergonha, seu criador está ganhando dinheiro público vendendo seu /snake oil/, agora com roupagem de métodos ágeis… e quem o pode culpar, sendo que nossa sociedade perdeu o conhecimento crítico? _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
