> Michael Ansley wrote: > > Hi, Frank, > > This is exactly why there are alternative solutions for trees. The mechanism that >you > are using traded input speed for 'queryability', and this is where you start to run >into > problems. Either you need to store redundant information (i.e.: the level) or you >need > to have a recursive or iterative procedure which steps back up to the top. > > Just for illustration, if you were using a node type to indicate the ID of each node > (say, something like 1, 1.1, 1.2, 1.2.1, etc.) then input into the table would be an > expensive operation, but querying this would involve only getting out the ID of the >node > that you were at, and splitting up the ID using the periods for separators. So if >you > wanted to traverse up the tree from node 1.2.5.3, (you know that it's at level three > simply by counting the periods)then the order would be: > > 1.2.5.3 > 1.2.5 > 1.2 > 1 It almost looks my very first attempt to do a tree, except that I had the node number not in one column but a column for each number: Instead of 1.2.5.3 1.2.5 1.2 1 I had 1|2|5|3 1|2|5|0 1|2|0|0 1|0|0|0 > And you only need the original node ID to do that, which is a single query. > > If you are not going to be doing this query often, and/or there are not going to be >many > levels, then you should probably consider the plpgsql solution, as it makes life >simple > for the programmer, and the cost is not really an issue, and you don't have to >maintain > redundant data. Denormalisation is a major pain when you start having to maintain >it. What exactly is the problem with it (are you referring to the scheme I proposed or to the 1.2.3-type scheme)? Actually, I don't really know now why I left my original idea. I guess it looked to simple. I think I will stick with my recursive parentid PL/pgSQL-trigger type schema for now. I'll just have to get into that PL/pgSQL stuff which I haven't properly looked at so far. Would this be a denormalized table then? The level information would be redundant but linked with the other columns via the trigger, hence there's nothing much that could go wrong . . . or is there a hidden maintenance penalty? Cheers, Frank
