On 18 Nov 2009, at 11:46, 7zark7 wrote: > > 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?
Christopher Lenz has a great discussion about this very problem: http://www.cmlenz.net/archives/2007/10/couchdb-joins Cheers Jan --
