Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

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

by jerrygarciuh (Curate)
on Feb 28, 2004 at 15:40 UTC ( #332480=note: print w/ replies, xml ) Need Help??


in reply to Re: Efficiently Walking Large Data Structures Stored in Multiple Tables
in thread Efficiently Walking Large Data Structures Stored Across Multiple Tables

Mark,
That is a great idea! I can make the curriculum admin wizard do the heavy lifting as the items are being added/reordered.
Thanks! Off to work on it...
jg

_____________________________________________________
"The man who grasps principles can successfully select his own methods.
The man who tries methods, ignoring principles, is sure to have trouble.
~ Ralph Waldo Emerson


Comment on Re: Re: Efficiently Walking Large Data Structures Stored in Multiple Tables
Download Code
Re^3: Efficiently Walking Large Data Structures Stored in Multiple Tables
by adrianh (Chancellor) on Feb 28, 2004 at 17:28 UTC
      If you're dealing with a database that can handle tree structures natively, maybe. But, I read the articles on doing tree structures as sets and I was ... underwhelmed. If all you need is the next page and there is only ever one next page, then deal with it that way. If you need a true parent-child structure and a way of asking for all parents without wanting to explicitly code it into your SQL and have it handled correctly by the optimizer ... good luck without Oracle or PostgreSQL.

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

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

        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.

        If all you need is the next page and there is only ever one next page, then deal with it that way.

        I did have the words "If" and "might" in my post y'know ;-) If all you need is the next page then it's obviously overkill. If you're doing more complex stuff a more generic solution is worth looking at.

        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.

        Erm. No they're not. The queries are damn quick. You have a representation that leverages the things that RDBMS are good at. .

        As for difficult to get right - not particularly in my opinion. Takes a little time to get your head around the representation - but the operations to access nodes and subtrees are pretty simple. Insertion is the only vaguely complicated operation.

        Hmm... I feel a meditation coming on...

      whilst recursive queries are fun, as you can do a whole lot of lookups and join them together in one sql statement; they do take a long time to run, significantly degrading performance. The flatter you can make the structure of the database, especially the often used tables, the faster the retrieval -- unfortunatelly this also means you end up with extra effort in maintaining the tables, as they start having redundant data (not fully normalised).
        whilst recursive queries are fun, as you can do a whole lot of lookups and join them together in one sql statement; they do take a long time to run, significantly degrading performance.

        Take another look at the bits of the thread on using a nested set representation for hierarchical data. Flat structure, normalised data and fast queries. Some performance degradation on insertion, but since people usually read and update a lot more than they insert it's rarely an issue.

        As for recursive queries - the old chestnut about premature optimization comes to mind. That and the fact that several databases have explicit support for hierarchical structures and appropriate optimisations to make access to those structures efficient - even if they set C.J. Date spinning in his grave ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://332480]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2014-08-30 04:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (291 votes), past polls