PS - storing only an immediate parent id would be the solution for an infinite tree depth.
On Fri, Feb 22, 2013 at 1:48 PM, Andrey Kuprianov < [email protected]> wrote: > Storing immediate children in a parent is a bad idea in a sense that you > will never be able to traverse your tree back to the root, given a child > node. > > Storing all in one doc - you will run out of space before you know it. > Documents have a finite length and the larger the document, the slower it > will get to serialize and unserialize it. > > Storing just an immediate parent in children might result in a costly > multiple read operations, if you want to get root of the tree given an > arbitrary child. > > Therefore the only feasible solution is to store references to the parent > chain - i.e. ancestors - starting from an immediate parent and ending with > a tree root. > > > Here's a simple calculation for ancestors approach: > > Suppose the maximum document size is 1MB. A uuid is 32 characters in > length + taking into account commas and brackets, then the depth of your > tree (I am not taking content into account) could be roughly: > > ((32 + 1)*n + 2 - 1) = 1024 * 1024 ==> n = 31775 levels > > However, max document size is configurable from the settings (as of > CouchDB 1.2) and could easily be up to 4GB, giving you over 130mil of > levels. Should be enough... :) > > > > On Fri, Feb 22, 2013 at 1:14 PM, Michael Heuberger < > [email protected]> wrote: > >> thanks andrey and svil >> >> depth is infinite. in theory a message can have million replies forth and >> back. similar like a very long email thread. >> >> i think storing ancestors ą la andrey would be too much hassle but works >> well for few levels. >> >> svil, what did you mean with dicts and with keeping all children in one >> doc? can you tell me more? >> >> thanks, >> michael >> >> >> On 22/02/13 17:27, svilen wrote: >> >>> my rough guess: >>> >>> if it's finite depth, then all in one doc: >>> - list of (item or (list of ...)) >>> - or same with dicts >>> >>> else, one doc per message keeping just link-to-parent, >>> or multiple links-to-grand...grand-parents and/or root. >>> similar to the strategies in SQL - nested etc. >>> keeping all chidlren of same node in one doc is also possible.. >>> >>> in any case either traversal or storing or both will be >>> difficult. >>> >>> ciao >>> svil >>> >>> On Fri, 22 Feb 2013 17:13:01 +1300 >>> Michael Heuberger >>> <michael.heuberger@**binarykitchen.com<[email protected]>> >>> wrote: >>> >>> Hello guys >>>> >>>> I'd like to store messages in a tree like structure. Whenever you >>>> reply to a message, then the original message becomes the parent >>>> message. >>>> >>>> How would you implement something like this in CouchDB? Just curious >>>> and need a little guidance + advice here. >>>> >>>> Thanks, >>>> Michael >>>> >>>> -- >>>> >>>> Binary Kitchen >>>> Michael Heuberger >>>> 4c Dunbar Road >>>> Mt Eden >>>> Auckland 1024 >>>> (New Zealand) >>>> >>>> Mobile (text only) ... +64 21 261 89 81 >>>> Email ................ [email protected] >>>> Website .............. http://www.binarykitchen.com >>>> >>>> >> -- >> >> Binary Kitchen >> Michael Heuberger >> 4c Dunbar Road >> Mt Eden >> Auckland 1024 >> (New Zealand) >> >> Mobile (text only) ... +64 21 261 89 81 >> Email ................ [email protected] >> Website .............. http://www.binarykitchen.com >> >> >
