Not at all :)
I've been trying to explain what Moshe and Konstantin describe succinctly - that relating items (not just nodes) is a universal problem that deserves a more comprehensive solution than what can be handled by an adjacency model. I've seen the adjacency model in a heavily-related system, and it wasn't good. Well, this reminds me of the Medaimatic's presentation about AnyMeta - a CMS the guys developed and maintain. They were refering to everything as a "thing". Apart from the fact that that forced us to drink a lot of beer in short time, we realised that their "everything is a thing" eaquals the "everything is a node" theory circulating the Drupal community. I think that merits consideration. Apart from purely philosophical arguments - this concept has the benefit of simplifying things like relationships, classification, permissions, etc...
Relations between nodes (in the above context) can be explicit: * books for example Or implicit: * via taxo terms * search results * linking between pages Relations are defined within certain domains: * for example by different vocabularies * child-parent * part of Observations like that make me believe that relation should be considered a more general term - reflecting only fact that things (cheers) are somehow related to other things, and there maybe an order imposed in that retaionship. The exact structures behind the relationships should be indicated by relationship types - trees, graphs, whatever. This will allow using uniformly both explicit and implicit ones - treating similarly relations within a book, and realtions implied by the occurrence of different taxo-terms. As an example for the latter have a look at http://mediamatic.net Each different page has a central thing and related things. The guys calculate those reations it using a 'distance' metric based on the tags and maybe additional info. It has some really cool concepts behind it. Click on keywords related to a thing to see how the relation changes.
I hope to be part of this conversation as it progresses, and I would love to spend more time on the hier module. As is often the case, I seem find myself with time OR resources, but never both. Why do I have the same feeling.
I agree that thrashing on a heavy-update system would be the biggest problem with a nested set algorithm. My first modification was to introduce a depth field to be able to move about the tree more easily. Just drop the sequential numbering of indexes and use the whole integer or float number space, while preserving the ordering in the tree. This will require a far rarer re-indexing after inserts or updates.
I hope we can try a few of these out and benchmark them against realistic data. Unless there are clear delineations for what works when, I'd lean to a "one size fits all" approach. Of course, I'm saying this without the benefit of context. me too
Cheers, Vlado