Re: Como começar com Banco de dados NoSql
Não é tratado. :) Em MongoDB não existe JOIN. Você consegue "o
mesmo efeito" de-normalizando o banco (duplicando informações). Você
resolve o mesmo problema com uma abordagem diferente. ;-)
Usuário com cidades você duplica a informação de cidade no
documento "Usuário" (já que cidades não costumam mudar de nome com
frequência), se o seu foco for listagem de usuários com a cidade onde
ele reside ou armazena a lista de usuário dentro do documento
"Cidades", se o seu foco for mostrar uma listagem de cidades,
opcionalmente mostrando os habitantes dessa cidade.
Outra alternativa é usar DBRef, apesar de não ser geralmente
recomendado: http://www.mongodb.org/display/DOCS/Database+References
Isso (referências) é algo que deve ser tratado na aplicação, não no cliente.
Eu resolveria assim:
Usuarios:
objectID -- este é o ID [1]
nome
cpf
cidade -- nome da cidade
Cidades:
objectID
nome
estado
Para saber qual estado o usuário mora:
usuario = db.usuarios.findOne( { cpf : "000.000.000-00" } )
cidade = db.cidades.findOne( { nome : usuario.cidade } )
print cidade.estado
Quantas pessoas moram numa cidade:
cidade = db.cidades.findOne( { nome: "Curitiba" } )
db.usuarios.find( { cidade : cidade.nome } ).count()
Por isso que você duplica dados: não tem join, então você tem que
fazer mais consultas.
davi
[1] - tem um motivo pra não termos id númericas auto-incrementáveis:
http://www.mongodb.org/display/DOCS/Object+IDs
2012/2/3 Fagner Patricio <fagner.patricio@gmail.com>:
> 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 <davividal@gmail.com> escreveu:
>
>> 2012/2/3 Fagner Patricio <fagner.patricio@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
Reply to: