[Nitro] OG vs Active Record

Robert Mela rob at robmela.com
Thu Aug 23 11:49:27 EDT 2007

I can appreciate the convinience of using adjacencies.   But there are 
as you suggest other criteria.

Where I work there's a tree of about 38,000 nodes changing a few times a 
day.  The amount of hand-editing that goes on is near nil, though the 
simplicity of adjacencies has been useful in debugging.

The simplicity of adjacencies is a much larger factor if your tree is 
small and there are good reasons to take the short-cut of manual edits 
or manual generation.

The broadest solution would be maintaining the adjacency list 
*alongside* the nested set.   Simply add a parent_id field to each 
node.  You can hand-insert a node, and run a script to have the system 
place it in the nested set.

Alternatively, you can have a utility script that regenerates the 
adjacency list after an insert.

Jonathan Buch wrote:
> Same as Nested Sets, Nested Intervals are hell with inserting/updating.  They
> additionally have a limitation on the depth/size of the tree.  While this is
> ok for small sets of data, bigger ones it rules out.
> Again, the pure complexity makes it very much impractical to do stuff
> 'by hand'.  Updating here is quicker than with NestedSets it seems, although
> right now the code from G looks like it'd also use ~4 queries (only a quick
> glance, haven't looked at actual queries).
> Nontheless, both, and NestedIntervals in particular, are incredibly
> interesting and very nice for many usecases.
> On the topic of caching, caching is a hard problem....   I'm now more for
> caching the end result and not a single query (which is Georges' stance as
> well I think).
> Jo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070823/5c88df7d/attachment.vcf 

More information about the Nitro-general mailing list