CouchDB - Vc acredita?

Bom, nao eh algo como o Acre, mas…

Das minhas primeiras brincadeiras com esse trem eu tirei algumas conclusoes… o que vcs acham:

Sim, lindo ser document oriented, controle de versao, mtos usos pra isso. Mas dae vem, JSON ?! WTF ?! Nao consigo entender, os caras qrem por auth no trem dae tu vai fazer uma aplicacao web com banco + JS ? Cabou? POrra?!?! Eu nao acredito! Nao consigo conceber isso mentalmente.

Nao seria melhor um adaptador nativo, que trouxesse os dados mais..humm nao-parse-necessario cmo json? Json eh um lixo pra parsear, lento pra porra.

Eh isso..talvez nao tenha entendido algo mto bem, por isso, esta.

Bracetas cumapdis,

Cara,

eu acho que quando estes paradigmas novos (Banco Orientado a Documento pelo menos para mim é novo, não sei quando foi criado) surgem eles dão uma pirada na cabeça mesmo. Deve ser a mesma coisa que quem programava proceduralmente viu quando a O.O surgiu.

Aquela “tabela” (documento) sem padrão, cada objeto JSON de um jeito e tudo junto, um samba do criolo doido.

Nao cara, qto a isso eu acho interessante, e encontrei ateh uns usos.

Minha birra (nao entendo/conformo) eh com JSON, e essa ideia de applicacao soh couch + JS

Se isso te conforma, poderia ser pior, poderia ser XML ehehehe. Bom, eu considero JSON bom o bastante… e acho que a idéia dos caras é que vc possa consultar o banco diretamente por javascript, sem necessidade de nenhum adaptador mesmo. Pelo que sei, essa arquitetura em JSON permite mais possibilidades nas consultas, se aproveitando da estrutura dos objetos.

Mas eh lento! Quase tao lento qto XML. Tem todo o trampo de serializar, passar pro ruby , soh pro ruby ter de deserializar e dar um parse no trem…

Bom, sei lah isso tb, soh tenho na cabeca a comparacao XML/JSON/AMF por exemplo, que amf eh soh umas 300x mais rapido… (protocolo da adobe binario pra comunicacao flash player <> server)

Sim, eu imagino um driver de banco, a la gem install postgres, gem instaa couch..heheh, que passasse isso binario/nativo/rapidamente…..

nofxx, acho que a idéia da coisa seria ter um banco de dados “escalavel”, querendo ou não, várias aplicações tem seus gargalos em BD, com o CouchDB seria possivel fazer um cluster com replicação, e colocar uma camada HTTP na frente do banco, na tentiva de escalar o mesmo, com um load balancer…

Post bem legal sobre dando uma introdução: http://blog.sweetspot.dm/tech-babble-resting-with-couchdb/

Abraço!

Marcos, se a quantidade de dados for grande, deserializar vai demorar de qualquer jeito =). To por fora de como é o AMF, mas acho que aí entra nossa responsabilidade de puxar os dados aos poucos. Não sei se estou falando besteira, porque estou começando a testar o couch e não fiz nem um teste com muitos dados… é mais achança mesmo =).

tchandy, Isso tudo eh lindo qdo eh aberto teus dados. E se precisar de qualquer tipo de auth? Ja era….

Fernando, a sim, com ctz.

Mas eu ainda acho que: talvez um banco híbrido ae apareça. Tu possa fazer “report tables” digamos, seriam orentadas a documentos. E relacional, ou o vaporware maior, o banco OO. Falava isso na apresentação do maglev.
Ou um driver nativo, que vc consuma (e/ou faça auth?) o couchdb…

Ou eu preciso eh terminar de ver o peepcode pq nao entendi bulhufas….

nofxx:

Bem, banco OO não é vaporware. Banco OO sendo usado com Ruby é. =p

O Nuxlli resumiu bem o que eu qria…:

e seja feliz

hehe…

Mereghost, pra mim era mosca branca isso ae… qual o mais famosinho ?

nofxx:

No mundo Smalltalk esses bancos são até que bastante usadas. O seaside inclusive pode ter os dados persistidos em bancos desse tipo, normalmente a referência é para o GOODS ou Magma. =)

Aliás, para bancos muito grandes (nivel Petabytes) OODBs, até onde sei, são preferênciais.

Meio mudando de assunto, alguém sabe a quantas anda o maglev? Nunca mais ouvi falar dele…