Take facebook\'s private messaging system where you have to keep track of sender and receiver along w/ the message content. If I were using MySQL I would have multiple table
You are going to need some kind of link between the two collections (users and messages).
Personally, I would keep it simple and add two extra fields to track the id of the sender and recipient, something like this:
{
_id: /* whatever_id */,
message_body: "This is the message",
date_sent: 2010-04-20T10:35,
sender_id: /*id_of_sender*/,
recipient_id: /* id_of_recipient */
}
The sender_id
and recipient_id
fields would just hold value for the appropriate user (most likely some ObjectID instance, although you can assign whatever you like) which corresponds to the _id field for the appropriate entries in the users collection. You would be able to query these appropriately to grab the messages you are after (or count them, or whatever else).
Another approach might be to effectively do the same thing, but to use a formal DBRef for the sender and recipient rather than just putting their IDs in. This would probably work just as well but I'd tend to go with the previous solution just because it is simpler and probably easier to query.
Both solutions would need to do another round-trip to the DB to grab the appropriate user documents (for displaying the "from" and "to" names for example).
Edit:
It would appear I have misunderstood what you are trying to achieve - I didn't know Facebook messaging incorporated any concept of threading. However, the solution you have presented above looks sound. Personally, I'd stick in the IDs for the users rather than their names (alice & bob), but it looks pretty workable apart from that.