Handling shared objects in Nosql (documentstore)

Theres one thing that I haven't understood with document databases and that's how to handle shared objects. Take this these two d开发者_开发问答ifferent objects/documents:

Email
    BelongsTo (User object)

Comment
    WrittenBy (User object)

The user is the same user in both documents.

• Are the actual user stored in the documents or some kind of reference (as in RDBMS)
• How are changes to the user handled (new first name etc)?

---

It depends on the NoSQL implementation you use. You could do it a few ways: if you're using JCR (JackRabbit, CRX, etc) you could actually store a Reference to a user node, or you could go the relational approach and store a user node's address.

---

I would say it depends on how you are planning on consuming the data. E.g if it is read intensive and you only access username of the User in object, then perhaps it would be better to duplicate that info in comment as well. This would of course lead to higher update costs if you allow change of username and that it's important to have comments updated with the latest username. We have used document storage for our read-models and went the route with duplicating data, since we instead built effective views/documents made for one view-context. Sure the updates got more resource intensive, but for us that was ok. I've been working with the other construct as well, using "manual" references between doc1 and doc2 based on ids. A bit more manual work but much less magic than with O/RM's.

There's a classic example with BlogPost --<1:N>-- Comments, where the comments could be contained by the post our be accessed via a ID. Again, how will you use this? Will you ever use comments without also displaying the post? Are you always interested in the comments when looking at a post? Is there underlying limitations of total storage of a document size like 16MB in MongoDB? Then you might need to split apart.

I know a very vague response but it's also a very "it depends on the use case" question.