Re: Re: Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables

Why underwhelmed?

I have not had occasion to use the nested set representation, but I have multiple friends who have. And it certainly worked as advertised for them.

Unless you have some concrete experience of the nested set representation not working as advertised, I'm going to have to heavily discount what you have to say. Even then I'd be interested to see the implementation since I know full well how easy it is to accidentally turn an efficient query into an inefficient one.

Comment on Re: Re: Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables

Replies are listed 'Best First'.
Re: Re: Re: Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables by dragonchild (Archbishop) on Feb 29, 2004 at 04:11 UTC
I'm not saying that it works or doesn't work. I have no experience in that regard. What I am saying is that the nested set representation looked like a lot more work than CONNECT BY in Oracle. It also looked like something would be very easy to mess up and that I would want to put in a bunch of PL/SQL routines (or, at least, provide at the DBIx:: level). ------ We are the carpenters and bricklayers of the Information Age. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]
Re: Re: Re: Re: Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables by tilly (Archbishop) on Feb 29, 2004 at 04:46 UTC
Earlier you wrote, Now, you could build the queries using some module (???), but the queries are very very very slow and very very very difficult to get right. Again, good luck. I wouldn't want to try ... Now you are admitting that you don't have experience to back that dismissal up. Fine. Based on reported experience I believe that the queries to do nested set trees are somewhat complex, but if you have a guide (eg Joe Celko's implementation) in front of you it is not that hard to get it right. Furthermore in practice they are quite fast to execute. Modifications being more expensive than selects, which is OK since in practical applications (eg a threaded view like discussion sites do) you tend to find that selects are more common. They have further benefits over any kind of iterative requerying in that the usage pattern fits how relational databases are designed. In particular you eliminate a lot of round trips that stress latency and your query optimizer. If your situation looks like this, then for all of the apparent complexity, knowing that nested set representations of trees are effective can be a lifesaver. (Quite possibly in a literal sense.)	[reply]
Re: Re: Re: Re: Re: Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables by dragonchild (Archbishop) on Feb 29, 2004 at 21:13 UTC
Fair enough. I spoke before fully evaluating the situation. Now, I think I'm going to try an implementation of nested set trees, just to be able to understand it better. Out of curiousity, is there an implementation of this on CPAN? ------ We are the carpenters and bricklayers of the Information Age. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]