Numa situação hipotética de haver as entidades Produto e Categoria, fazer o embed da categoria no documento de produto inviabilizaria obter apenas as categorias (para um menu, por exemplo). Trabalhar com referências/links seria semelhante ao modelo relacional. E a outra opção seria duplicar, tendo uma coleção de categorias e a categoria também dentro do documento de produto, mas essa ideia não me agrada (e tem a questão de maior espaço em disco). Como você avalia situações assim?
Michael, essas são as situações em que o paradigma relacional mais "incomoda"... Mas veja só, se você está fazendo uma tela de CRUD por exemplo, cadastrando o produto é totalmente viável você ter uma coleção de categorias, para que ela seja utilizada para preencher o "combo" de categorias. Já no caso da exibição da categoria na busca de produtos, a categoria "embedada" seria muito mais performático.
A grande questão aqui é a Integridade Referencial, que no caso do MongoDB não existe e então controlamos pela aplicação ( Devs: grandes poderes, grandes responsabilidades). Temos que tomar um pouco de cuidado quanto a isso.
Já a questão do espaço em disco, não vejo como um problema, isso era um problema quando os bancos relacionais foram criados, inclusive esse era um dos problemas que eles vieram pra resolver. Hoje a duplicação de dados é algo pra se considerar normal. Mas claro, temos que avaliar bem as situações que as aplicações requerem, porém, num modo geral é isso,
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Numa situação hipotética de haver as entidades Produto e Categoria, fazer o embed da categoria no documento de produto inviabilizaria obter apenas as categorias (para um menu, por exemplo). Trabalhar com referências/links seria semelhante ao modelo relacional. E a outra opção seria duplicar, tendo uma coleção de categorias e a categoria também dentro do documento de produto, mas essa ideia não me agrada (e tem a questão de maior espaço em disco). Como você avalia situações assim?
Michael, essas são as situações em que o paradigma relacional mais "incomoda"... Mas veja só, se você está fazendo uma tela de CRUD por exemplo, cadastrando o produto é totalmente viável você ter uma coleção de categorias, para que ela seja utilizada para preencher o "combo" de categorias. Já no caso da exibição da categoria na busca de produtos, a categoria "embedada" seria muito mais performático.
A grande questão aqui é a Integridade Referencial, que no caso do MongoDB não existe e então controlamos pela aplicação ( Devs: grandes poderes, grandes responsabilidades). Temos que tomar um pouco de cuidado quanto a isso.
Já a questão do espaço em disco, não vejo como um problema, isso era um problema quando os bancos relacionais foram criados, inclusive esse era um dos problemas que eles vieram pra resolver. Hoje a duplicação de dados é algo pra se considerar normal. Mas claro, temos que avaliar bem as situações que as aplicações requerem, porém, num modo geral é isso,