> > http://www.evolt.org/article/Four_ways_to_work_with_hierarchical_ > >data/17/4047/index.html > > I have to say I've seen better writeups on this topic - so be > warned :) that looks very much like '1st 5 things i found about recursive data'.
> Choosing a strategy for storing hierarchical data in a database > depends largely on how you will be retrieving the data (what kind > of queries do you need to make). exactly. and one more thing, the way u store data may not be the way u retrieve it - i.e. u have one original copy that presents everything as is, and one pre-calculated/calculable-on-the-fly view/copy which u use for queries. and for differnt queries u may have different extracts/views. For example, storing a graph as links and nodes is fine to keep the original data, but is quite difficult for most (graph algorithmical) queries - procedural recursion is not SQL's piece of cake. Thus storing additional transient-closure of the graph (all possible end-to-end paths) is a way to go for some targets which need paths. Probably there are other solutions for other targets. have fun svil --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
