Bit of a design question, hope you can provide some guidance:
I'm writing an internal wiki-like web application, and one of the
use-cases is to comment on a document.
Domain model is simple:
a Comment class with text, date, and a collection of child comments.
My first implementation stores the comment tree in a single document,
since it is very easy to serialize and deserialize, and the comment tree
itself can be thought of as a holistic "document".
This works great, but now running into an issue on how to best support
revision conflicts when multiple people are commenting at the same time.
If I were to keep the tree stored in a single document, I would have to
load the two conflicting versions in code, manually combine the trees,
and then save a new version, correct?
From a storage-perspective, it seems it would be simpler then to store
each comment as its own document, with a "foreign key" of sorts pointing
to a parent comment, which would be much less likely to have conflicts.
But then it seems I'm forcing a relational model into a document-based DB.
Any thoughts on this?
Thanks,
Z
