[drupal-devel] menu memory usage

[Bèr Kessels]

you just described the general relation system :)

read more on: 
http://drupal.org/node/34168
http://www.webschuur.com/relations_system
http://drupal.org/node/28480

and have a look at the tables at 
http://drupal.org/node/28480#comment-42850
(and the commetn above it for some descriptions)

Ber

Op maandag 24 oktober 2005 12:30, schreef Konstantin Käfer:
> Hello,
>
> recently, I have been experimenting with nested sets. Nested sets
> provide a rather simple technology to store huge (menu) trees in a
> database without having to loop through them using recursion. As
> recursion eats more time as the tree grows large and if there are more
> levels, it is not adviced to use this technology in relational databases.
>
> The nested set (or nested tree) works by adding two  meta values to the
> record, one left value and one right value. Let's take the following
> menu structure:
>
> root [1/24]
> -- create content [2/7]
>    -- page [3/4]
>    -- story [5/6]
> -- my account [8/9]
> -- administer [10/23
>    -- access control [11/12]
>    -- settings [13/20]
>       -- content types [14/15]
>       -- posts [16/17]
>       -- users [18/19]
>    -- users [21/22]
>
> For an extensive example, see
> http://www.phpriot.com/d/articles/php/application-design/nested-trees-1/ind
>ex.html.
>
> The left and right values are in the square brackets, the first is the
> left one and the second the right one. The advantage is, that it is easy
> to obtain all necessary leafs with one single query.
>
> I don't like the current taxonomy system. I just want a tree where I can
> attach nodes to and let drupal build the complete navigation structure.
> Another disadvantage of the taxonomy system is also that building real
> breadcrumbs is very costly (due to recursion). Yesterday, I started a
> module (named ouline) that uses a nested tree instead of taxonomy to
> classify content. At the moment it is already capable of building a
> breadcrumb with one single query:
>
>     SELECT node.nid as nid, node.title as title
>       FROM outline AS selector
> CROSS JOIN outline AS outline
>         ON (selector.lft BETWEEN outline.lft AND outline.rgt AND
> selector.tid = outline.tid)
> CROSS JOIN node AS node
>         ON (outline.nid = node.nid AND node.status > 0 AND node.moderate
> = 0)
>      WHERE selector.nid = <node id> AND outline.nid != selector.nid
>   ORDER BY outline.lft
>
> If the outline table would be integrated within the node table, you even
> need to JOIN one table less. Another advantage is that the nested set
> does not mess around with "weight" propertys. There is only one single
> allowed order (that can be changed very easly though, for example using
> drag and drop with AJAX and regular buttons as fallback).
>
> Konstantin Käfer
>
> Karoly Negyesi schrieb:
> > Hi!
> >
> > Probably most of the devels have not noticed
> > http://drupal.org/node/34755  "when I enable all modules in core, the
> > menu array eats over 800K of RAM".  As we now have menu-otf which will
> > be badly abused and (almost) all nodes  will be put in the menu
> > hierarchy instead of stuff like About Us, FAQ etc,  we can look ahead
> > for situations where someone locks himself out of his  drupal cold
> > after a node submission because the menu tree will grow too  large. I
> > know this can not be solved for 4.7, it's too late, but let's  discuss
> > it.
> >
> > Regards
> >
> > NK
 Bèr
-- 
 PGP ber at webschuur.com
  http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
 PGP berkessels at gmx.net
  http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://drupal3.drupal.org/pipermail/development/attachments/20051024/4ac33aa3/attachment.pgp