|
|
Posted by Jerry Stuckle on 09/01/06 19:33
mootmail-googlegroups@yahoo.com wrote:
> Jerry Stuckle wrote:
>
>>All I can say is - that has got to be one of the WORST implementations
>>I've ever seen. Talk about making a simple problem complex - this takes
>>the cake.
>>
>>I wouldn't even try implementing something like this.
>>
>>Rather, keep it simple:
>>
>> id parent description
>> 1 null books
>> 2 1 nonfiction
>> 3 1 fiction
>> 4 null electronics
>>
>
>
> At first glance, something like a preorder-tree traversal setup is
> needlessly complex. I agree that the example you provided is much
> easier to visualize conceptually.
>
> I agree because I have made that mistake in the past. We had a project
> that involved massive trees (we're talking the bill of materials for an
> entire automobile down to an individual screw), and went with the
> simple 'parent' scheme, but were too deep into the project before we
> suddenly regretted it. A scheme like that is easy to set up, but a
> nightmare to use and maintain.
>
Interesting. I've implemented this for things like a flight database -
all scheduled flights throughout the world, with each departure and
destination airport, etd and eta, etc. And been able to use recursive
queries to find possible flight combinations to get from one destination
to another - one single query would get it. And although there are a
lot of parts in an automobile, there are also a lot of scheduled flights
in the world for a year.
If you can do recursive queries, it works quite well. And this was with
DB2, which handles recursive queries quite well.
> To get a node and its children from the example you gave (known as the
> Adjacency model), you have to rely either on recursion or knowing
> exactly how many levels exist. The former introduces significant
> overhead while the latter is just bad hard-coding. Using a more
> advanced tree algorithm allows for a much easier time working with
> nodes and children. The link provided earlier
Not that much overhead if you can do the recursion in SQL. One query
can get everything.
> (http://dev.mysql.com/tech-resources/articles/hierarchical-data.html)
> is a great resource for seeing the different queries required to work
> with either scheme.
>
> I doubt the OP will be dealing with trees quite as large as the ones I
> needed to use, but if you can deal with a bit of complexity up front,
> you can save yourself a lot of extra work later on.
>
And if you can do your recursion in your SQL statements you don't even
need the complexity.
> And speaking of the original post...I didn't quite understand what you
> were asking. If you were asking for advice on getting the # of items
> in each category, perhaps you could use the examples on that page
> linked to for getting all the children of a node, and then WHERE'ing it
> to include only those nodes whose lft & rgt are 1 apart (meaning they
> have no children).
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|