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

71062.1056_at_compuserve.com (--CELKO--) wrote in message news:<c0d87ec0.0203041245.491fcf7c_at_posting.google.com>...
> I think that your entire approach is wrong, but it is
> probably too late to save yourself.

I think that is a bit negative. As I said in my post, I didn't design the database, I am just using it. I have just done a bit of research to learn to use it and discovered the problem with the circular references. What is so wrong about my approach?

<SNIPPED: Good explanation of Adjacency  List Model versus Nested Sets Model for  representing trees in a graph>

I agree that the Nested Sets Model you described looks very promising. If I ever design a database that uses a tree structure somewhere, I will definitely consider using it. However, I can't now because the database structure is already in place. Also, I think that the nested sets model cannot be easily extended to allow for graphs instead of trees, or am I wrong?
You see, the structure I am describing is a graph that should be _represented_ in a tree. This will work fine as long as there is no circularity in the graph.

A few questions about the nested sets model:

• How does the performance of INSERT queries compare to the adjacancy model? Are they slower, faster, does it differ from time to time? I guess they are slower because on average you will have to modify multiple records instead of just one? This is fine though, inserts are usually performed much less frequently than selects.
• Is it possible to use graphs instead of trees, meaning a many-to-many relationship?
• What about getting all the descendants of a Unit without losing the hierarchical structure, for example to place them in a tree control? Will that usually be faster?

--
Stijn
OddesE_XYZ_at_hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail