Snell-Pym

But is that the way to go? Perhaps we can avoid the complexity by taking other approaches. After all, in my particular application, nesting of structures can be avoided; we just need three levels of 1-dimensional hierarchy followed by the user hierarchy, since nested objects can just be handled by adding a fourth level of 1-dimensional hierarchy as a 'sub-object ID' and then subdivide each sub-object within the serialised IRON object graph as per its storage manager. Perhaps we just need arbitrary dimensionality at one level, simplifying our key relationships.

Or perhaps I just need to stick to providing a simple B-Tree, and force higher dimensions to be handled with one of the various techniques for mapping multidimensional data onto a one-dimensional store (such as the Pyramid Technique or grid file)? Or just store an R-Tree or hyperspatial GiST within a B-Tree by using the B-Tree as a store of numbered blocks, and using them as variable-length index and leaf blocks, so the B-Tree deals with the problem of free space tracking and reclamation for us?