Naz,
>The ability to manipulate trees with single queries
>was what made them so scalable in my mind. What is
>the better way to handle large frequently updated trees?
>This is the best method I know, I'd love to
>learn of a better one.
For large frequently updated trees & DAGs I prefer edge lis
Really? The ability to manipulate trees with single queries was what
made them so scalable in my mind. What is the better way to handle large
frequently updated trees? This is the best method I know, I'd love to
learn of a better one.
- Naz.
Peter Brawley wrote:
> Naz writes
>
> >The definitive
Naz writes
>The definitive answer to anything that
>requires trees in SQL is nested sets.
They are not definitive when the tree is large and must be updated
frequently.
PB
-
Naz Gassiep wrote:
The definitive answer to anything that requires trees in SQL is nested
sets. I have written a
The definitive answer to anything that requires trees in SQL is nested
sets. I have written a tutorial on the subject, as this is about the
most asked question in DB relational data modeling.
http://www.mrnaz.com/static/articles/trees_in_sql_tutorial/
Enjoy :)
- Naz.
Peter Brawley wrote:
> tbt
tbt
>the number of levels in this table is unknown and the query should work
for any number of levels
please provide a sample 'select' query in mysql
That's a graph, which is recursive, so you need an sproc. See edge list
sprocs at http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch2
