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.
-Dave Ross >If data isn't changing too frequently, aggressive caching can pretty >much >negate the cost of the adjacency list, but again, that's not >applicable in all situations either. > >Yeah, we used to have a lot of static data which accounted for a lot of >our database hits every page load (like security). We started caching >the whole query in the application scope and pulling out what we needed >with a q of q. That took about as long to retrieve the data, but the >database was freed up a whole lot in the process. > >~Brad ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:230876 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
