Usando um document database como backend do ZODB
Osvaldo Santana
Como o pessoal daqui deve saber está acontecendo a edição 2010 da
PyCon em Atlanta/EUA.
Alguns desenvolvedores andam postando informações sobre o que está
acontecendo por lá durante esses dias. E muita coisa interessante
aconteceu relacionado a 2 assuntos que tem despertado a minha atenção
recentemente: o framework web repoze.bfg (que ainda não conheço o
suficiente pra indicar a ninguém mas parece ser bem promissor) e sobre
experiências dos pythonistas com bancos de dados não-relacionais
(majoritariamente MongoDB, CouchDB e o bom e velho ZODB).
Mas hoje um twit do @MacYET me chamou a atenção: "@MacYET i wonder how
MongoDB could be used as backend alternative to the ZODB e.g. for
catalog mass data - dooing some research now #pycon"
Quando li essa frase algo ligou na minha cabeça e um número infinito
de idéias surgiram.
Imaginem armazenar os objetos Python dentro do MongoDB e com isso ter
toda a flexibilidade e poder do ZODB e ao mesmo tempo poder usar
índices, as ferramentas de indexação full-text ou a linguagem SQL-like
deles para buscar os dados?
Eu imagino que seja algo viável de se implementar. Arriscaria até a
dizer que pra um bom conhecedor do ZODB poderia implementar esse
backend muito rapidamente.
Valeu,
Osvaldo
--
Osvaldo Santana Neto
Fone: 41-9244-1646
http://www.pythonologia.org
David Kwast
Fico pensando se o Django um dia terá um ORM (ou outro nome melhor para esta camada) mais genérico, para deste modo, suportar alguns bancos alternativos. Mas ao mesmo tempo, essa idéia me parece muito absurda, pois tudo no Django depende do "Schema" gerado no models.py . Talvez só se o Djando tiver outra camada paralela para cobrir outros bancos, isso já não me parece tão absurdo.
No momento, quando preciso usar um banco de dados diferente, sempre caio no Buzhug (que no fim não passa de um banco relacional simples sem SQL). Até agora não peguei nada muito específico que precise de um banco focado em documentos.
Osvaldo: O Zope usaria o banco (MongoDB) com esse novo backend sem nenhum problema, certo? Ele nem quer saber até aonde o backend vai para guardar e buscar os dados?
Fico imaginando como serão os banco de dados do futuro (daqui uns 10-20 anos)...
[]'s
David Kwast
--
-----------------------------------------------------------------------------------------------------------------
# Você recebeu esta mensagem porque está inscrito no grupo [nosql-brasil]
# O e-mail para envio de mensagens é [mrnn-...@googlegroups.com]
# Para desinscrever-se: mrnn-brasil...@googlegroups.com
#
/* Mais opções acesse: http://groups.google.com/group/mrnn-brasil?hl=en
-----------------------------------------------------------------------------------------------------------------
Grupo para pessoas que não relacionem SQL com o mal e o No-SQL / MRNN com o paraíso.
-----------------------------------------------------------------------------------------------------------------
*/
Carlos Ribeiro
Acho legal esse movimento em direção ao DBs alternativos. Ainda vou pegar um dia para estudar o ZODB e os bancos de documentos da moda (Mongo e Couch).
Fico pensando se o Django um dia terá um ORM (ou outro nome melhor para esta camada) mais genérico, para deste modo, suportar alguns bancos alternativos. Mas ao mesmo tempo, essa idéia me parece muito absurda, pois tudo no Django depende do "Schema" gerado no models.py . Talvez só se o Djando tiver outra camada paralela para cobrir outros bancos, isso já não me parece tão absurdo.
Vi um artigo recente em um blog sobre isso:
http://www.allbuttonspressed.com/blog/django/2010/02/4-things-to-know-for-NoSQL-Django-coders
O artigo contém dicas interessantes. A camada "ORM+NoSQL" já está funcionando, o pessoa mostra alguns exemplos, e discute a importância de fugir de "joins" escondidos e de outras coisas que são armadilhas para bancos não-relacionais.
Nesse propósito lembro uma discussão recente nossa (não lembro se foi aqui ou na python-brasil), com o Marinho Brandão, a respeito da possibilidade de se implementar um ORM genérico que permita abstrair bem a implementação do banco, seja ela relacional ou não relacional. Ainda duvido que isso seja realmente possível ou que dê um resultado "ótimo"; acho que aplicações baseadas em bancos não-relacionais deveriam estruturar seus modelos de outra forma, para aproveitar melhor as características do banco subjacente. Mas isso é papo para outra thread :-)
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com