[drupal-devel] nested sets (was menu memory usage)

[vlado]

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