On Wed, Dec 13, 2000 at 04:49:51PM -0800, Josh Berkus allegedly wrote:
> Stuart,
>
> > I don't think I'd be comfortable with having the node_level column in the
> > table structure. First, because you can derive that value using a function,
> > it's duplicate data. Second, if you decide to take an entire segment of your
> > hierarchy and move it under another node (by changing the value of
> > node_linkup/ParentCategoryID), you'll need to recalculate all of those
> > node_level values. And all the node_level values underneath it.
>
> I can see that. I suppose it depends on the data you're storing. The
> project I was working on tracked grocery inventory for a delivery
> service, and thus each item had a fixed "level" in the heirarcy (Food
> Class, Food Type, Manufacturer, and Item) and thus while items might get
> reassigned *across* the heirarcy, they did not get re-assigned *up and
> down* the heirarcy.
Indeed. If the structure 'rarely' changes, having to do an expensive
update may be acceptable, if it increase the overall performance
significantly.
> Also, I can't think of a way to represent the tree in pure SQL without
> having the level identifiers (and a fixed number of levels).
Storing only the parent for a record doesn't require you to keep track
of levels, since this information can be reconstructed by following the
chain of parent id's until you reach the top of your tree.
Storing the children for each record (like I'm doing) works exactly the
same. Just follow the 'path' (for instance 'Automotive Transport/Cars')
to find the category you're looking for.
Cheers,
Mathijs
--
"A book is a fragile creature. It suffers the wear of time,it fears rodents, the elements, clumsy hands."
UmbertoEco