Posted by R. Rajesh Jeba Anbiah on 02/07/07 06:54

On Feb 6, 5:06 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> R.RajeshJebaAnbiahwrote:
<snip>
> > 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/>
>
> 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.

As I said earlier, the categories kinda thing for a normal web
application will be very limited--the table data will be more or less
static. I'm expecting the table size will be 200-500 records. But,
when you take the breadcrumb, you have to show it is on every pages--
the headache is higher here. So, nested set architecture will be ideal
here or it's variants (my memory recalls two or more variants)

> 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.

As I said, my memory is vain on the theory of recursive SQL; but I
still know as I implemented nested sets will be ideal for showing
breadcrumbs. I'll lurk <news:comp.database.theory> sometime later.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Back to original message]