I structure things as trees because I want to be able to traverse them. When a user sees your tree and expects to be able to do tree operations on it, but discovers its just an illusion and they can do no such thing, then dissatisfaction sets in.
> And for the love of all that is good, if you actually need a tree, use a tree.
It’s in almost every section.
Also, it's mentioned at least three other times in the article before the conclusion. Just one example: "Do your items actually have to have a parent-child relationship, or do they just need to look like they do?" That's pretty clear.
But it also goes on with multiple examples that support their approach whilst neglecting storing data as real tree ("That sounds like a lot of work and potentially awkward-to-work-with data structure, especially if stored in a database" and "one way to get tree-structured data from a relational database with a SQL query is to write a recursive CTE (Common Table Expressions), which are just as fun as they sound"). You don't prove your point by using the most extremely examples of the "bad" approach.
The article is very vocal about shortcomings of storing trees as trees, but quiet about possible issues with the approach used.
It looks more like a emotional rant rather than an informative piece.
That's the whole purpose of the article. To neglect storing data as a real tree, hence the fake in the title.
It couldn't be more clear about it.
>It looks more like a emotional rant rather than an informative piece.
It gives descriptions and examples of several techniques, which will do fine for many simple use cases. Which is exactly what it promises.
This reaction seems more like an emotional rant rather than TFA.
In the namespacing example, it's trivial: the parent is the version of the name of the current node with one "namespace" less. E.g. /bar/boop/bleep's parent is /var/boop.
Similarly, the children of /bar are any nodes starting with "/bar/".