The stupid question is the question not asked | |
PerlMonks |
Re: Re^5: Efficiently Walking Large Data Structures Stored in Multiple Tablesby dragonchild (Archbishop) |
on Mar 01, 2004 at 02:28 UTC ( [id://332755]=note: print w/replies, xml ) | Need Help?? |
I can see how selection isn't very difficult. Nested set trees look to be optimized for retrieval. My issue is modification. Updates to where you stand in the hierarchy (promotion, for example) aren't incredibly hard, unless your entire department moves with you to someone that never had a department under them before. Deletion doesn't look to be a big deal - you simply have to deal with the same problem you have in CONNECT BY, which is what to do with the entities under you.
I guess my biggest problem with the whole notion is the fact that I affect record A. In Oracle's tree representation (and I'm assuming PG's, as well), that's the end of it. With nested set trees, I might have to re-number the entire hierarchy's intervals. Granted, that's the pathological case, but it's still something you have to code for. And, that has to be checked in every modification. (Maybe not DELETE, but definitely for INSERT and UPDATE.) Another thing that concerns me is how this might potentially affect triggers written against that table. Most developers work with tables that aren't nested sets. (I understand that's how RDBMS's think about things, but most developers of my acquaintance aren't as ... flexible.) The data structure, as a whole, looks very fragile to me. There's a lot of bookkeeping involved (unless I'm missing something obvious). ------
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
In Section
Seekers of Perl Wisdom
|
|