The structure I use that lets you do this has categories with:

id, parent_id, lbound, ubound, depth

all are integers.

id is the category id and defined with value (lbound - 1) parent_id is the id field of the parent lbound is the lowest id that can be allocated to direct decendents ubound is the max id that can be allocated to direct decendents depth is the tree level

You start with the root node with perhaps id 0, parent id 0, lbound 1, ubound 100000 (or probably maxint)

Each time you add a node at a given level, you allocate the node a portion of the available range. e.g. the first child of the root may have id 1, lbound 2, ubound 500. The next child at that level might have id 501, lbound 502, and ubound 1000. A child of the first child at this level might have id 2, lbound 3, ubound 100, and so on.

You can now do various hierarchical searches very efficiently using this design, and for yours, the parents of node 'N', have:

id < N.id and ubound > N.ubound and depth < N.depth

The test on depth in fact isn't necessary.

All decendents of a given node have:

id > N.id and ubound < N.ubound

Direct decendents of a given node have:

id > N.id and ubound < N.ubound and depth = N.depth + 1

etc.

You have to be semi-smart about how you divide the range at a given level in order to not run out of ranges, based on expected number of levels, and numbers of items at each level, but it's typically not impossible to manage at all. If you have to adjust the node ID's and ranges to expand or contract the tree to create space then this is possible too of course, with some operations just requiring a single update to a portion of the tree, others requiring a more complex set of updates to manipulate the tree. The best thing is to try and be smart at the point of adding items such that adjusting the tree isn't required.

There may be a simpler solution for your requirements, but perhaps this is of some help.

Nick