The 'obvious' representation of a tree in a relational database uses relations to represent edges in the graph.

This is called out in SqlAntiPatterns, since a naive implementation of tree traversal then has to make many queries, typically one per node. TreeInSql solves this by changing the representation.

If you have a procedural language driving the database then there is another way which does not change the representation. The trick is to process tree nodes in breadth-first order. After processing a level in the tree, the next level is selected en masse. Tree traversal can then be done with a number of queries proportional to the depth of the tree. Alternatively levels of the tree are accumulated into a temporary table for further processing.

This algorithm can be adapted to traverse DirectedAcyclicGraph''''''s (but then needs SelectDistinct), or to traverse arbitrary DirectedGraph''''''s (but then needs an in-memory or in-database visited flag to avoid visiting the same node twice).

EditHint: Merge with TreeInSql? Not sure about that - it might be better to move the bulk of TreeInSql to a new page FullPathStoredAtLeaves and have TreeInSql refer there and here and to whatever other schemes people have for dealing with graph representation in SqlLanguage.