One important consideration, particularly with sensitive data, is that a nested set tree lacks the ability to generate orphans. With adjacency lists, the best case scenario is you suddenly have a record that's not in the tree, but worst case is a cascade delete. That can be very bad, if you have a bug in your app that fails to prevent this. With a nested set, losing an ancestor doesn't remove you from the family, it just removes one of the intervening layers.
There's a more than just ease of access vs. performance to consider in the equation. Nested sets also require twice the extra space (two keys per record, rather than one). cheers, barneyb On 1/31/06, Dave Ross <[EMAIL PROTECTED]> wrote: > we hit similar issues with nested sets... the costs of inserts, moves and > deletes became too great. We use a pushdown-stack (which mimics recursion) > stored proc in MSSQL and it's pretty snappy depending on the number of nodes > selected (actually more important is how deep the nodes are). In general I'm > a fan of adjacency list over nested sets. I think the nested set model can > quickly get out wack as systems grow. The *wow* factor of pulling any branch > with a simple query quickly wears off. Either way, it's important to look at > the hierarchical problem you are trying to solve rather than blindly choosing > one approach over the other. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:230877 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
