title: Too much data duplication in mongodb?
body: <p>I'm new to this whole NOSQL stuff and have recently been intrigued with mongoDB.  I'm creating a new website from scratch and decided to go with MONGODB/NORM (for C#) as my only database.  I've been reading up a lot about how to properly design your document model database and I think for the most part I have my design worked out pretty well.  I'm about 6 months into my new site and I'm starting to see issues with data duplication/sync that I need to deal with over and over again.  From what I read, this is expected in the document model, and for performance it makes sense. I.E. you stick embedded objects into your document so it's fast to read - no joins;    but of course you can't always embed, so mongodb has this concept of a DbReference which is basically analogous to a foreign key in relational DBs.    </p>
  
  <p>So here's an example:  I have Users and Events;  both get their own document,  Users attend events, Events have users attendees.  I decided to embed a list of Events with limited data into the User objects.  I embedded a list of Users also into the Event objects as their "attendees".  The problem here is now I have to keep the Users in sync with the list of Users that is also embedded in the Event object.  As I read it,  this seems to be the preferred approach, and the NOSQL way to do things. Retrieval is fast, but the fall-back is when I update the main User document, I need to also go into the Event objects, possibly find all references to that user and update that as well.</p>
  
  <p>So the question I have is, is this a pretty common problem people need to deal with?  How much does this problem have to happen before you start saying "maybe the NOSQL strategy doesn't fit what I'm trying to do here"?   When does the performance advantage of not having to do joins turn into a disadvantage because you're having a hard time keeping data in sync in embedded objects and doing multiple reads to the DB to do so?</p>