Wondering about using the acts_as_nested for a model but concerned about
the performance overhead of having to rewrite the table each time and
entry is added or removed(and locking it while it’s happening or risking
data integrity probs). Wasn’t really familiar with the structure so did
a little reading up on it, and one solution to this seems to spreading
the table out, so that [using the table in the API as an example],
instead of:
ID | PARENT | LEFT | RIGHT | DATA
1 | 0 | 1 | 14 | root
2 | 1 | 2 | 7 | Child 1
3 | 2 | 3 | 4 | Child 1.1
4 | 2 | 5 | 6 | Child 1.2
5 | 1 | 8 | 13 | Child 2
6 | 5 | 9 | 10 | Child 2.1
7 | 5 | 11 | 12 | Child 2.2
you would do this:
ID | PARENT | LEFT | RIGHT | DATA
1 | 0 | 10 | 140 | root
2 | 1 | 20 | 70 | Child 1
3 | 2 | 30 | 40 | Child 1.1
4 | 2 | 50 | 60 | Child 1.2
5 | 1 | 80 | 130 | Child 2
6 | 5 | 90 | 100 | Child 2.1
7 | 5 | 110 | 120 | Child 2.2
Then if you added a new entry 8, which was a child of 2, for example,
you could give it a lft of 121 and a rgt of 122, meaning no full-table
re-write. Of course this fails down eventually and does require at least
a partial table rewrite (and you’d prob want to do a multiple of more
than 10 on the entries to begin with), but it would certainly cut down
the probs. Anybody got any comments? There’s probably a good reason why
the AR implementation takes the full-rewrite approach, and I’m pretty
much a noob (not a programming background) so feel free to shoot me down
in flames.
The new table would look like:
ID | PARENT | LEFT | RIGHT | DATA
1 | 0 | 10 | 140 | root
2 | 1 | 20 | 70 | Child 1
3 | 2 | 30 | 40 | Child 1.1
4 | 2 | 50 | 60 | Child 1.2
5 | 1 | 80 | 130 | Child 2
6 | 5 | 90 | 100 | Child 2.1
7 | 5 | 110 | 120 | Child 2.2
8 | 5 | 121 | 122 | Child 2.3
Cheers
Chris T