Denormalization is still important. Taking that comment example a bit further, if you need user records tied to the comments, you're going to want to include all the user information that you need for displaying the comment in the comment record itself. Mongodb doesn't have joins. So if you have 200 comments on a post by different people, you're going to have to grab those users from mongo in a separate call, and if you're sloppy about it, 200 separate calls.
If your users really need to change their user names, you might run a job that updates the comments async.
I use MongoDB for my startup (yabblr.com) and have quite a relationship data stored in my entities.
For example, my user entites have an array of commentId's stored inside of them.
Whenever I fetch 1 or 1000 users from the database, a framework that i designed will look at the entire list of users and build a single list of commentIds based on that list.
Then I do one more lookup on the database to find all comments in my new list of comments.
Then a final pass over the users looks up the commentId associations and inserts the actual comment object into the user object.
Finally the list is passed back to the consumer. Its 2 database calls. It does require that there are 2 iterations over the first call (one to gather up comment Ids and one to associate comments with users) but since its being done in the application layer, its much easier to scale.
Denormalization is still important. Taking that comment example a bit further, if you need user records tied to the comments, you're going to want to include all the user information that you need for displaying the comment in the comment record itself. Mongodb doesn't have joins. So if you have 200 comments on a post by different people, you're going to have to grab those users from mongo in a separate call, and if you're sloppy about it, 200 separate calls.
If your users really need to change their user names, you might run a job that updates the comments async.