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. -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+Qfho+vp7ysmoMtb=x1pmjshwncj-l8zyss9qdmkppx28o...@mail.gmail.com