2012/2/3 Fagner Patricio <fagner.patricio@gmail.com>:
> Olá!!Como você faria esse relacionamento, digamos, no MySQL? :P
>
> 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?
>
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.