>> Para mim a única real vantagem que produtos como CouchDB tem sobre >> bancos SQL é que são pensados desde o início para escalar. > > Acho que não entendi... eßes dois parágrafos teus acima não eſtão em > contradição? Pelo pouco que ſei, CouchDB é menos eſcalável a não ſer > para um tipo de problemas bem eſpecífico.
Pode ser, eu conheço pouco, é que pensei em alguns parecidos que são escaláveis "de fábrica". Li um artigo a respeito e botei todo mundo no mesmo saco, falha minha. > A hiſtória eſtá cheia deßes ſiſtemas. Tipicamente, aßim que os SGBDs > SQL ganham as capacidades dos ſiſtemas eſpecíficos, eles morrem... um > que parece já caminhar neße ſentido é o BigTable e ſeu /clone/, o > Hadoop. Não captei muito bem. O que estariam fazendo de errado com o Hadoop ? > Ißo dito, o SQL tem de fato limitações importantes devido a não ſer > relacional... e não há perſepctivas de curto prazo para ſubſtituir o > SQL, embora por um lado (o lógico) o Alphora Dataphor > <http://dataphor.org./> ſe aproxime dißo e até eſteja para ganhar uma > interface PoſtgreSQL e, por outro (o fíſico), o Yahoo! Evereſt > <http://www.scribd.com/doc/3159239/70-EverestPGCon-RT><http://glinden.blogspot.com/2008/05/yahoo-builds-two-petabyte-postgresql.html> > talvez já aponte um caminho. > Esse projeto do Yahoo é interessante, mas não ouvi falar mais dele. Seria interessante ter mais detalhes. E mais interessante ainda se fosse (ou já é?) código aberto. Podem me chamar de neurótico, mas atualmente fico com receio de investir em tecnologias de empresas que podem pertencer a MS que depois puxaria o plug do projeto :). > Hm, pois é, ißo já foi muito diſcutido aqui. Essencialmente, o SQL tem > limitações em relação ao modelo relacional que dificultam ſeu uſo com > programação orientada a objetos, mas o problema mais grave é que o > mapeamento correto entre o modelo relacional e orientação a objetos é no > nível dos tipos, e não das relações (tabelas) como coſtumam fazer os > ORMs por aí. > > Ou ſeja, ſiſtemas como o CouchDB podem ſer a reſpoſta certa, mas para o > problema errado... É verdade, o que eu quis dizer, e acho que não consegui, é que alguns desenvolvedores escolhem os SGDB simplesmente porque é o que há mais disponível como persistência. Não se preocupam em entender como funciona. Isso é receita para problemas seja qual for essa forma de armazenar. A não ser que alguém cuide disso para eles, ou um DBA, ou algum sistema que escale sozinho muito bem. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
