How can Postgres represent a tree of row IDs? - sql

Question

I want to represent a file-and-folder hierarchy in a Postgres 10 database. A structure like
Photos/
|-- Dog.jpg
|-- Cat.jpg
|-- Places/
|-- Paris.jpg
|-- Berlin.jpg
Songs/
|-- Happy.mp3
would be represented as something like
| id | filename | parent_id |
|----|------------|-----------|
| 1 | Photos | null |
| 2 | Songs | null |
| 3 | Cat.jpg | 1 |
| 4 | Happy.mp3 | 2 |
| 5 | Places | 1 |
| 6 | Berlin.jpg | 5 |
| 7 | Dog.jpg | 1 |
| 8 | Paris.jpg | 5 |
The database would track multiple users, and each user would have their own file-folder hierarchy.
I've been reading up on Postgres's ltree extension, and it seems like the solution to my problem, but I don't know if it is, and it's difficult to test. The labels seem like arbitrary strings -- is it possible to tell Postgres that a label should be an ID field in the same table? Would I need to create one initial root node for each user, only let them attach children to that or children of children of that, then issue a select * from nodes where path ># that rootnode, can you select descendants that way?
Or am I forcing Postgres to do something it was never intended to do, when I should be looking at other kinds of database?

Answer 1

To answer correctly: It depends on your use case.
If your trees are very static (sub nodes change not very often) then ltree is a really good choice. You can do very fast and comfortable queries for sub nodes and ordering. In that case I would do a single root reference for each user as you mentioned.
On the other hand: moving a sub tree in ltree could force you a huge rewrite of the ltree data structure. E.g. if you have a tree like 1.1.1, 1.1.2 and 1.2.1 and you want to change the order of the sub trees in first level after the root, all three values have to change their data.
So, if you tree structure is very dynamical I would try the structure you mentioned above: saving the parent node in an adjacency list (and maybe an index for ordering) and do the query with recursive CTE queries
https://www.postgresql.org/docs/current/static/queries-with.html
http://schinckel.net/2014/09/13/long-live-adjacency-lists/
Last but not least you could try it with the "nested sets" structure (https://en.wikipedia.org/wiki/Nested_set_model).
Every approach has its very own benefits and drawbacks. You have to do a very detailed analysis and maybe create some prototypes to test which one is the best for you.
Further reading:
https://medium.com/notes-from-a-messy-desk/representing-trees-in-postgresql-cbcdae419022
https://explainextended.com/2009/09/24/adjacency-list-vs-nested-sets-postgresql/