No mundo SQL, quando temos, por exemplo, uma tabela de usuários e uma tabela livros que pertencem a estes usuários é comum criarmos um campo 'usuario_id' na tabela de livros, o qual é preenchido com o id do dono do livro. Gostaria de saber qual é a melhor maneira de implementar isso dentro do mongo, se criando um array dentro do documento do usuário e ir adicionando livros ali ou se fazer algo semelhante ao que é feito no mundo SQL, criando uma coleção de usuários e uma de livros, incluindo uma propriedade 'usuário_id' no documento do livro? Ou se ainda há uma forma mais interessante de fazer isso?
5
respostas
respostas
Associação de ID no mundo NoSQL
Oi Nandes, acho que a melhor forma de modelar é aquela que acreditamos ser extraída do contexto.
No mundo SQL, nos acostumamos a modelar os dados da forma que descreveu justamente para evitar vários problemas como duplicação de dados, ter consistência, etc.
No mundo NoSQL, a consistência é "perdida" em prol da flexibilidade. Então, não conheço uma forma melhor que outra nesse sentido.
Se você quer consistência, faça como no SQL padrão de costume, separe as coleções, etc.
Se os livros não existem de forma independente e eles estão sempre associados a um dono em específico, talvez não faça tanto sentido assim ter uma coleção só pra eles.
Faz sentido?
Só não compreendi bem esse parágrafo final, eu pensei em colocar os livros em um array no objeto do usuário, porém achei que ficar fazendo update no objeto poderia atrapalhar o desempenho, por isso optei por criar uma coleção para os livros acrecentando em cada um a propriedade user_id.
Hm, desempenho talvez se o documento crescer muito. No começo deve ser imperceptível, além de que, depende das operações que pretende fazer.
O exemplo real da aplicação envolve 3 entidades, a empresa, seus projetos em andamento e os relatórios diários sobre esses projetos, relatórios esses que são bem dinâmicos (por isso a preferência pelo NOSQL). A necessidade de registrar o id seria a de relacionar os relatórios aos seus respectivos projetos. Faz sentido?
Faz sentido sim.
Só fiquei na dúvida se a escolha pelo NoSQL deveria ser por isso mesmo. Se o relatório é um texto longo, por que não colocar em um campo TEXT do SQL padrão?
Porém, se é um formulário com campos dinâmicos, configuráveis, etc. Ai sim, o NoSQL te dá mais flexibilidade.