Schema Design Best Practices -- what to do without joins, when properties can be updated?

[Tim]

Say I have the below collections, and I want to display the User.Name
with a comment. But User's can update their Name, so I wouldn't want
to store this with the comment. In the relational world, this was
solved by joining to the User table to display the Name, but that's
not an option with NoSQL / Mongo.

What is the best practice to solve this? I'm assuming it's to just
store the UserName with the comment document, and then if the User
does update their Name, I'd go through all of their documents and
update the UserName? Or is it to nest the entire UserEntity document
inside the CommentEntity document, and if the actual User collection
is updated, then update all of their documents? Even though the ladder
sounds strange to me, I suppose it's the most flexible since I would
be able to get any of the User data I might need, not just
theUserName.

UserEntity
Id
Name

CommentEntity
Id
UserId
UserName // First option above
UserInfoEntity // Second option 2 above
CommentText

Thank you,
Tim

[MTheory]

you must store users as document in this format for not to use relation. and all your problems will be resolved.

var users =

[

{ 

Name : "UserA", 

Comments : [ {CommentText: "Comment 1"}, {CommentText: "Comment 2"} ]

},

{ 

Name : "UserB", 

Comments : [ {CommentText: "Comment 1"}, {CommentText: "Comment 2"} ]

}

]

[Tim]

Gougle groups is a good example actually... Comments are related to a
topic though, and multiple users can comment on that topic. How would
you accomplish that?

[Tim]

That's how would you accomplish that with the original question in
mind, that the user's name can change over time.

[Daniel Harman]

Multiple options...

1. Store with comment and update with name change. Fast assuming typical use case of infrequent name changes.
2. Do the join each time. Not as quick, but don't early optimise. As long as user table indexed by user objid it may be quick enough for now... Especially if you only retrieve user name field not whole record.
3. Just store users objid with comment, and have middle tier user cache so resolve outside of mongo. Makes more sense if you start to need more stuff about users cached up.

Maybe even use a different in memory tech for the caching. E.g. Redis perhaps.

Personally I'd start with 2 and see how project/performance reqs evolve....

Dan

Sent from my iPad