Le mardi 21 avril 2009 à 14:42 -0300, Daniel Gaspary a écrit :
> Não necessariamente, do pouco que conheço, o SQL Alchemy(feito em
> Python), abstrai o que é possível, mas permite que se use recursos
> únicos do SGBD em questão.
De fato o SQL Alchemy é a exceção. ¡Pudera haver equivalentes noutros
ambientes de programação!
Mas, como tu, conheço pouco dele, preciſava m’aprofundar.
> Quanto a questão de não conhecerem SQL, concordo e acrescento: tão
> logo esse tipo de banco tipo couchDB se torne mais popular, problemas
> vão surgir devido ao fato que o problema real é que as pessoas querem
> armazenamento infinito, sempre disponível e com rápido acesso. Mas
> essas pessoas não querem precisar estudar sobre o armazenamento.
> Claro, há exceções, mas no geral é isso.
>
> 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.
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.
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.
> Outra característica é que esse tipo de banco se adequa melhor ao
> modelo OO, não existe o clássico problema de se mapear algo OO para
> algo orientado a tabelas e linhas. Mas isso é questão de conhecer o
> que se usa, e não ficar culpando um banco SQL por não se encaixar
> direitinho ao Java*-way-of-life.
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...
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7344 gTalk: xmpp:[email protected]
+55 (11) 3854 7191 ICQ: aim:GoIM?screenname=61287803
BRAZIL GMT-3 msnim:[email protected]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
