Re^3: Trees in SQL, adjacency lists and sorting.

You certainly can't do that with the single table solution either. Such a branch is iterative and therefore cannot be expressed as an RSE whichever RDBMS solution you choose.

Everything but the troll

Comment on Re^3: Trees in SQL, adjacency lists and sorting.

Replies are listed 'Best First'.
Re^4: Trees in SQL, adjacency lists and sorting. by saberworks (Curate) on Jan 09, 2006 at 23:00 UTC
I beg to differ. In fact, here is an article about it: click	[reply]
Re^5: Trees in SQL, adjacency lists and sorting. by DungeonKeeper (Novice) on Jan 10, 2006 at 09:35 UTC
About twelve years ago I had a similar idea to the one in the article for a multiple concurrent junior-senior structure but it isn't as simple as the article pretends. A whole family of stored procedures are in fact needed to support the complexity the writer either isn't seeing or isn't presenting and the developer is more likely to be told to come up with something simpler, especially if the DBMS doesn't have stored procedures. Update: the complexity I refer to occurs when the structure has to support insert update and delete by concurrent users. Everything but the troll	[reply]
Re^6: Trees in SQL, adjacency lists and sorting. by saberworks (Curate) on Jan 10, 2006 at 16:00 UTC
Actually I wrote a PHP class based on that article (and others that are similar) which requires no stored procedures and lets me pull out data with one query at the expense of slower inserts (it takes more than one query to insert data). I will be happy to post the source, although I have no perl counterpart.	[reply]