Re: [X] Tree/Graph structure in many-to-many relationship, avoiding/detecting circularity

>> As I said in my post, I didn't design the database, I am just using
it. <<

The real world of data processing is gtoo often cleaning up other people's errors <g>.

I'd get a book on graph algorithms and see if you can translate circular reference into SQL.

>> Also, I think that the nested sets model cannot be easily extended
to allow for graphs instead of trees, or am I wrong? <<

You are right and I have been trying to come up with something better than the adjacency list or adjacency array for years. Nested sets can model a lattice or a tree, but that is all.

>> - How does the performance of INSERT queries compare to the
adjacancy model? Are they slower, faster, does it differ from time to time? <<

Slower in theory, but faster in practice. In the nested sets model, the (node,lft,rgt) tree structure is in a separate table which is very small. All or most of the structure fits into main storage easily for a few thousand nodes.

Most people who use an adjacency list model put the node information in and make the parent just another column -- look at the Oracle scott/tiger sample database.

>> - Is it possible to use graphs instead of trees,meaning a
many-to-many relationship? <<

No, but you can put different heirarchies over the same nodes

>> - What about getting all the descendants of a Unit without losing
the hierarchical structure, for example to place them in a tree control? <<

AQnythyig that deals with subtrees is much, much faster in nested sets than in adjacency list models. Received on Thu Mar 07 2002 - 14:00:17 CST