[Neo] is neo4j the correct tool to store trees?

TuX RaceR tuxracer69 at gmail.com
Tue Apr 6 16:45:01 CEST 2010


Thank you very much Craig for this detailed answer ;)
The last thing that seems slow to me would be to get a node ID given a 
path (eg /dir/dir2/dir3/...../dirN)
To do that, starting from the root node, I would have to query the 
root's CHILD(ren), search for the node which has the property name 
"dir1", then iterate the process until the lowest node "dirN". I feel I 
need some kind of index to index the CHILD(ren) at each depth.

Thanks
TuX


Craig Taverner wrote:
> You are right, the graph is a natural way to describe a tree (or a tree is a
> type of graph). I usually construct trees with a simple CHILD relationship,
> so each directory will have outgoing CHILD relationships to all
> sub-directories and files. You can traverse from the root to any file or
> depth using a traverser, but actually a more common pattern is to only
> iterate the relationships from the current node. That is the same as a 'dir'
> or 'ls' command. This makes it very easy also to visualize the tree in the
> GUI. When the user clicks the expand icon on a tree node, you iterate the
> children and populate the tree dynamically.
>
> Of course it is trivial to move branches around by simply re-linking (adding
> and removing CHILD relationships).
>
> Sorting children can be done in the client (during iteration of child
> nodes), or alternatively persisted in the database with ordering
> relationships between the child nodes. For example I sometimes use NEXT
> relationships to define order. Persisting it in the database is only useful
> if you have very large child sets, and don't want to load them all into
> memory at once. If they are extremely large, you can also remove the CHILD
> relationships (all but to the first CHILD), so that you don't have too many
> relationships from the parent. This problem is unlikely in any filesystem
> which has much more limited thresholds than neo4j, but it could happen in
> some some tree-like data.
>   



More information about the User mailing list