Olá!!!
Davi, minha dúvida é exatemente essa questão dos join, como isso é tratado
em banco NoSQL, pelo o que eu etendi no seu caso é duplicação de
informação!!
Mas o cenário é!!
Eu tenho informações de usuário e de cidades e quero relaciona-las!!!
Isso é possível em bancos NoSQL?
Em 3 de fevereiro de 2012 12:29, davi vidal <davivi...@gmail.com> escreveu:
> 2012/2/3 Fagner Patricio <fagner.patri...@gmail.com>:
> > Olá!!
> >
> > Davi, realmente não tenho conhecimento para falar sobre banco de dados,
> na
> > verdade nunca precisei usar um :), mas tenho confiança que os bancos
> NoSQL
> > serão o futuro, me simpatizo mais com o MongoDB, minha linguagem "mãe" é
> > python e me parece que eles são dão muito bem.
> >
> > Não entendo de modelagem de banco, seja ele SQL ou NoSQL.
> >
> > Eu seou admin de rede e o que me chama a atenção é questões de infra,
> como
> > redundância, balanceamento de carga e cluster e me parece que esses
> bancos
> > são feitos para isso.
> >
> > Mas eu queria discutir um cenário com você!!!
> >
> > Veja num banco relacional agente criar tabelas, por exemplo, "usuário"
> com
> > nome, data de nascimento e cidade certo?
> >
> > Ai eu crio outra tabela de cidades com informações de população e estado
> e
> > faço um relacionamento entre elas.
> >
> > Como isso ficaria no banco NoSQL como o mongodb?
> >
>
> Como você faria esse relacionamento, digamos, no MySQL? :P
>
> Realmente não entendi sua pergunta.
>
> Não existe JOIN em MongoDB (e parece-me que em NoSQL, no geral).
> Enquanto que isso pode parecer uma deficiência, deve-se olhar de outra
> forma: JOINs são necessárias?
>
> Pense neste cenário:
>
> Usuarios
> id
> nome
>
> Posts
> id
> titulo
> conteudo
> usuario_id
>
> Comentarios
> id
> post_id
> usuario_id
> conteudo
>
> Banco MySQL, faço JOIN e todo mundo fica feliz. Mas essa solução
> (e você como sysadmin vai concordar comigo e entender melhor) consome
> muitos recursos num ambiente com muitas requisições. Uma alternativa
> para melhorar o desempenho seria de-normalizar o banco. Assim você
> duplica informação, perde MUITO desempenho num eventual UPDATE, mas
> ganha na leitura. Basta "saber"* escolher o campo:
>
> Posts
> id
> titulo
> conteudo
> usuario_nome
>
> Comentarios
> id
> post_id
> usuario_nome
> conteudo
>
> No MongoDB, eu poderia fazer, ainda, o seguinte:
>
> Posts
> id
> titulo
> conteudo
> usuario_nome
> comentarios: array{
> id
> usuario_nome
> conteudo
> }
>
> Sim. Um array dentro do registro. Seria, mais ou menos, como se
> você pegasse todos os comentários de um post, serializasse e guardasse
> no MySQL como BLOB, mas sem a serialização. :-)
>
> Qual o problema: aqui estou supondo que você não vai ficar mudando
> de nome de 5 em 5 min. Se você ficar mudando de nome sempre, vou ter
> que procurar em todo o banco de dados por todos os campos em que
> esteja seu nome e fazer um UPDATE. É por isso que NoSQL é bom num
> ambiente que você faça mais leituras que updates. Apesar de as
> gravações serem extremamente rápidas, essa "maneira errada" de
> desenhar um banco faz com que UPDATES sejam custosos, lentos e
> difíceis, se não impossíveis.
>
> Mas voltando à sua pergunta: quer/pode elaborar melhor seu exemplo?
>
> davi
>
> * Quando eu digo "saber o campo" é na base do chutômetro, mesmo. :-)
> Algumas vezes você tem como bater o olho numa tabela e identificar os
> campos "imutáveis". Outras vezes vai ser no chute mesmo.
>
--
Fagner Patrício
João Pessoa - PB
Brasil
