Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of andrey.kouprianov@gmail.com
 designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5126FEC9.3080900@binarykitchen.com>
References: <5126F04D.8010305@binarykitchen.com>
 <20130222132727.5b04d528@dede>
 <5126FEC9.3080900@binarykitchen.com>
From: Andrey Kuprianov <andrey.kouprianov@gmail.com>
Date: Fri, 22 Feb 2013 13:48:10 +0800
Message-ID: 
 <CAG+HO1zKqUVhjRGWFz4zZpMXJkt2_7ApfrUHOXH9kvaaoBA4Sw@mail.gmail.com>
Subject: Re: Tree like structures in CouchDB
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=f46d040fa03cc7d84204d649bdee

--f46d040fa03cc7d84204d649bdee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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) =3D 1024 * 1024  =3D=3D> n =3D 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 <
michael.heuberger@binarykitchen.com> 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 =C4=85 la andrey would be too much hassle but w=
orks
> 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<michael.heuberg=
er@binarykitchen.com>>
>> 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 ................  michael@binarykitchen.com
>>> 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 ................  michael@binarykitchen.com
> Website ..............  http://www.binarykitchen.com
>
>

--f46d040fa03cc7d84204d649bdee--