3 ms·
I haven't done nearly enough research to back this point of view, but it seems to me that if you really need to make a recursive query over a data tree, you sho
by acjohnson55 12y ago
I haven't done nearly enough research to back this point of view, but it seems to me that if you really need to make a recursive query over a data tree, you should maybe reconsider how that tree is being modeled. The closure table model [1] is simple to query non-recursively, and unless your tree is pathological, it doesn't add that mcuh space overhead. I suppose though that a built-in recursive query might not be so bad though, if it's just a whole bunch of indexed row lookups within one query.
Perhaps there are situations where recursive queries really are the only solution. I'd love to hear some examples.
[1] http://technobytz.com/closure_table_store_hierarchical_data.html http://technobytz.com/closure_table_store_hierarchical_data....
- jsherer 12y agoHow do you determine if your tree is pathological? I.e., what types of tree structures would you find the closure table model to be pathological enough to warrant other modeling options?
- acjohnson55 12y agoGood question -- so the most pathological tree of n nodes would be one with depth of O(n). If this was the case, the closure table would be of size O(n^2). In tree applications I can think of--like an org chart or site comments--the depth is O(log(n)), in which case the closure table is just O(n). Note that this same kind of pathological tree would be hell for a recursive query too, just trading space for time.