in reply to Re: (OT?) Recursive sql queries?
in thread (OT?) Recursive sql queries?

Interesting article. Do you have any others? It was a teaser, but didn't provide methods for maintaining said list.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re^3: (OT?) Recursive sql queries?
by adrianh (Chancellor) on Feb 26, 2004 at 14:29 UTC
Re: Re: Re: (OT?) Recursive sql queries?
by stvn (Monsignor) on Feb 27, 2004 at 01:36 UTC

    The second part of the article actually talks about maintaining the tables as far as deleting sub-trees. And the third part of the article gets into inserting sub-trees. It gets more involved and complex as it goes, but if you are reading more than you are writing, this method seems pretty cool.

    -stvn
      if you are reading more than you are writing, this method seems pretty cool.

      Actually, most writing functions are easier too ;-) Update operations on subtrees and leaf nodes can usually be implemented in a single SQL statement.

      Insertion is really the only vaguely complex/expensive operation - and that's still just three SQL statements in a basic implementation.

      The only downside is that inserts can be expensive compared to just storing the parent ID. With the implementation Celko outlined in the article inserting a node is O(N).

      Still the average case isn't that bad. You can also make inserts less expensive on average by using increments larger than 1 and inserting in the "gaps" until a global renumbering becomes necessary - but since this makes the selects more complex, and most systems read/update a lot more than they insert, it's rarely worthwhile.