using path notation /../../.. for hierarchy

I've used to my own satsisfaction a path notation to store hierarchical information.

I've made a system for an educational institute and their educational programs have all kind op of dimploma's, modules and so forth and of course a number of courses. These things constitute a tree, with modules as nodes, and the actual courses and traings as leaves.

I used a 'path' like notation to indicate the place in the tree for each item.

A path ending in a slash denotes a node:   /study-A/foo/module3/

A path not ending with a slash means a course:  /study-A/foo/module3/physics101

Selecting all components of module /study-A/foo/module3/ becomes:

...WHERE path LIKE '/study-A/foo/module3/*'

and to weed out sub-modules:

...AND path NOT LIKE '*/'

So I did not use separate nodes and leaves tables, and stored everything in one table, overloading the row definition quite a bit. Nor did I use a 'parent-id' system to construct the tree. But it worked out very well for this application.

The lack of support for hierarchical structure (the famous lack of Bill Of Materials Processing (BOMP) support) is often mentioned. In practice it is to my knowledge compensated with additional complex libraries or modules, bypassing SQL.

So I am curious, is my approach discussed earlier and what does the c.d.t. community think of using path notation in this manner?

Greetings,

Henk Received on Sun Jun 08 2003 - 14:02:47 CEST