Em 13/09/2012 08:29, Guimarães Faria Corcete DUTRA, Leandro escreveu: >> 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. É uma boa notícia.
>> 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. Da mesma forma que os SGBDs estão evoluindo as plataformas de desenvolvimento também. Esta mais fácil e muit mais rápido construir aplicações que antigamente, logo é mais barato fazer de novo e consequentemente todas as transações passaram sim pelo sistema e serão validadas, exemplos não faltam e de cabeça cito duas: Marabraz e Porto Seguro, e contratar pessoas para fazer a carga nos novos sistemas ou dependendo do caso, deixá-lo simplismente morrer de inanição. Por você talvez não conhecer metodologias como DDD ( Domain Driven Design ) [1] é que você acha que só é fácil fazer no SGBD. Se falarmos em SOA ( Service-oriented_architecture )[2] então afirmaremos que independente de como a aplicação seja feita ela passará por estes serviços e será aplicado as regras. > > >> 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. Conheço sim, não sou DBA para escarafunchar ( se é que se escreve assim ) todas as funcionalidades do SGBD, mas fazendo uma ponderação, continuo apostando na facilidade da configuração em 1 linha do JBoss a esperar um SGBD chegar na mesma facilidade. Gostaria muito de ter esta dúvida, escalar horizontalmente a aplicação ou o SGBD, afinal de contas é uma questão de escolhas pois é muito fácil nos dois. Mas não tenho esta dúvida, hoje é na aplicação que reside esta facilidade logo não é uma escolha só minha. Latência é fácil de resolver com programação ( ops! ) pois um cache resolveria ,exemplo: "todas" as postagens no facebook são processadas em outros momentos e não no momento em que te avisou que foi gravada com sucesso, então você clica em salvar, postar, seja lá o que for e ele te avisa Postagem salva e te mostra em sua timeline, mas na realidade ele gravou em um repositório de dados próximo a aplicação e disparou uma outra thread para gravar no repositório físico, o que interessa é mostrar ao usuário que foi salvo, agora quanto não interessa pois vai ser gravado mesmo. Consumo de banda, é discutível pois ou esta embutido no custo do uso do sistema ou os servidores são separados por um cabo de par trançado em algum rack. Mudanças de contexto envolvido é transparente. > > >> É 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. Veja bem, não estou diminuindo a importância do SGBD. > > 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… E qual o problema? SGBDs relacionais estão no mesmo patamar que os SGBDs NoSQL em uma decisão de arquitetura de software, sim, é uma questão de assumir riscos ou não, mas estarão. > > Por isso o povo babou no Prevayler. Bleh! Desde quando fui a uma palestra em 2003 vi que era muito, muito pouco para o que estavam vendendo como solução. ( minha terapia não funcionou agora... hehehehe ) > Para minha vergonha, compartilho da vergonha. > seu criador > está ganhando dinheiro público vendendo seu /snake oil/, agora com > roupagem de métodos ágeis… putz, sofro com roupagens novas para os métodos ágeis... gosto de definir que o quê se tem vendido é falar que é método ágil para encobrir irresponsabilidades cometidas em diversos momentos... > e quem o pode culpar, sendo que nossa > sociedade perdeu o conhecimento crítico? O que seria sociedade mesmo? Acho que perdemos ela a muito tempo... criticar então... Se for um pensamento thelemico então.... vixi... [1] http://en.wikipedia.org/wiki/Domain-driven_design [2] http://en.wikipedia.org/wiki/Service-oriented_architecture _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
