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