Joe's best method is called the Nested Set Model, which is radically
different then the classic ID/ParentID model. It really works beautifully,
plus it works with every database model. I even have a version that runs
well in Access. With the Nested Set Model you can pull out specific
branches, find the path to a specific node, pull out the entire tree, etc.
It's really slick.
The Nested Set Model works by creating data boundaries around the tree-much
like XML does. I had to read the chapter a few times before it really
clicked, but once you get the principal concept, it becomes very intuitive.
-Dan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 30, 2000 11:36 AM
To: CF-Talk
Subject: RE: tree structure
I've seen two solutions.
One works if you have a classic tree arrangement of data:
parent child
1 2
1 3
2 4
4 5
3 6
cannot be done with a single SQL statement, and is relatively slow. I've
implemented it as a stored procedure in both MS SQL Server and Oracle.
The other solution, which I think Joe describes, involved organizing the
data differently, and looked great if you had that freedom. I'm not
describing it quite right, but it's sort of like assigning your items ids
that represent their place in the structure
1
11
112
113
2
21
211
2111
2112
22
and relying on the database's sorting abilities to give you what you want.
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
