I asked this over at SO and didn't get any responses after a couple weeks, so I figured I'd try SE...
- How do I update nested objects in MongoDB when data referenced in those nested objects changes?
- What are the pitfalls of simply storing IDs within nested objects and having the client look up the correct value to display?
I have an application that I believe could benefit significantly from using a document database (e.g. MongoDB) rather than the current SQL backend. The structure of the documents in the resulting model would have a fair bit of nesting involved (2-3 levels). The issue with this is that the contents of nested objects could potentially be updated outside of the context of the document that contains that nested object. Under a relational/normalized model, this is straightforward - whenever we update the nested object (i.e. database row), that update automatically gets pulled in via a JOIN. However, I understand that trying to do this sort of JOIN/lookup pretty much defeats the purpose of using a document database in the first place...
My fear (perhaps unfounded) is that any benefits I gain from switching to Mongo (e.g. eliminating complexities of serializing the data to/from the client, faster read/write, etc.) would be mitigated by the effort/complexity of having to find and update any document that uses an object that gets changed. I know there are ways to do this, but it seems extremely cumbersome and error-prone.
Relationships are unavoidable
To the best of my ability to sort this all out, I believe the relationships and the need to update nested data are unavoidable. Essentially, when inputting the data on the client side that would become the documents, users need to select items from a dropdown box. Some of the data in these items (e.g. the display name) will occasionally get updated. Any documents that reference these items need to be updated with whatever data the item currently contains.
Presently, the client receives all of the lookup tables (which populate the select boxes) as part of the application state. As such, my initial instinct is to simply store the ID (which will never change) of a reference item in the document and have the client look up the correct display value from its own state. This avoids the need to update all documents that reference a particular item and also eliminates any joins on the backend. However, I am afraid I'm missing something with this solution that could cause issues in my application down the line. The obvious thing is that this would result in a certain level of coupling between the client and the backend.
So this brings me back to my questions above:
- Is there a non-cumbersome/reliable way to update data in existing documents when that data references other objects that might change?
- Are there any pitfalls with my proposed solution of simply storing the IDs in the document and forcing the client to figure out what to show the user?