demerphq thanks for looking at this for me. I think the RAT would be very useful.
I'm fairly new to PM but I have a background in databases so naturally a db solution springs to mind (my mind at least). Do you have any links to documentation on the "everything engine" I'm not familiar with it.
Regarding links to everything engine, take a look at the bottom of any page on the site. Regarding a DB solution, yes sure it would have to be in DB. But the question is how. More explicitly but briefly the problem is how do you efficiently handle thread watching when you are using a parent pointer representation for the reply tree.
Yes thats correct. As is quite normal in DB stored trees. Its the easiest way to store a tree as it means that the entire dataset can be stored in only one table. If you have child pointers then you need two tables, one base table for the leafs and one associative table showing which children are associated to which parents. So for instance with parent pointers to find all children of a node you say
However the real contrast is totally different representations, such as using overlapping line segments to determine parenting. In this model you store root pointer information along with left/right markers. The root of the thread has a left marker of 0 and a right marker of ∞, child nodes have subsections, so if there were two children they might have bounds of (0,∞/2) and (∞/2,∞). (With ∞; being some huge number). The nice thing about this approach is that you can do things like find the descendants of a given node (call it X) quickly:
select * from nodes where nodes.root_id=X.root_id
and X.left<= nodes.right and nodes.left<=X.right
The advantage of this approach for node watching is that you can easily determine if the descendent tree has changed, by simply doing the above query to determine the latest timestamp. Doing similar with parent pointer or child pointer representations is much more computationally intensive.