|
|
Posted by Jerry Stuckle on 02/06/07 12:06
R. Rajesh Jeba Anbiah wrote:
> On Feb 5, 7:45 pm, Michael Fesser <neti...@gmx.de> wrote:
>> .oO(R.RajeshJebaAnbiah)
>>
>>> Answer is Nested Set Model architecture <http://dev.mysql.com/
>>> tech-resources/articles/hierarchical-data.html>
>> Definitely not. In most cases a nested set structure is total overkill,
>> especially if all you need is a simple parent-child relation. Running
>> some queries recursively is quite cheap (even cheaper with prepared
>> statements) and also much simpler compared to the very complex issue of
>> handling a nested set.
>
> My memory is vain on the theory of the recursive SQL, but the
> overhead in nested set architecture is only when you insert the data,
> but not while fetching. Usually the categories structure won't change
> often--IOW, it's more or less static than dynamic. There is some good
> stuff on nested sets here <http://dev.e-taller.net/dbtree/>
>
> --
> <?php echo 'Just another PHP saint'; ?>
> Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
>
Rajesh,
A side note. The nested set isn't appropriate - and IME it seldom works
very in real life. The nested set has its own problems like inserting
new items into a large table. It's also more complex to manage than a
simple parent/child relationship. I agree with Micha that is is way too
complicated for a simple job like this.
Hopefully MySQL will get recursive SQL soon. It's quite handy for
managing parent-child relationships and other tree types. And it
handles other types of relationships as well - including ones where
nested sets don't work.
But meanwhile he can do it with stored procedures.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|