3 ms·

But what do you do if the child needs to refer to the parent, or the parent needs to know its children. An illusion of a tree is only useful insofar as you don'

But what do you do if the child needs to refer to the parent, or the parent needs to know its children. An illusion of a tree is only useful insofar as you don't really care about it being a tree. 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.

Semaphor 3y ago
They mention it a lot, and again at the end in the cautionry section: > And for the love of all that is good, if you actually need a tree, use a tree. It’s in almost every section.
- kroolik 3y ago
  Its only in the conclusion, though.
  - adrianmonk 3y ago
    "Fake" is literally the first word of the title. If a fake version of something had all of the qualities of the real thing, then it wouldn't be fake. It would be real. 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.
    - kroolik 3y ago
      The article describes fake trees thus Fake in the title, yes. The article also asks the question you quote, true. 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.
      - coldtea 3y ago
        >But it also goes on with multiple examples that support their approach whilst neglecting storing data as real tree 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.
tleb_ 3y ago
Then use a tree if you need a tree?
coldtea 3y ago
>But what do you do if the child needs to refer to the parent, or the parent needs to know its children. 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/".

Semaphor 3y ago

They mention it a lot, and again at the end in the cautionry section: > And for the love of all that is good, if you actually need a tree, use a tree. It’s in almost every section.

kroolik 3y ago
Its only in the conclusion, though.
- adrianmonk 3y ago
  "Fake" is literally the first word of the title. If a fake version of something had all of the qualities of the real thing, then it wouldn't be fake. It would be real. 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.
  - kroolik 3y ago
    The article describes fake trees thus Fake in the title, yes. The article also asks the question you quote, true. 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.
    - coldtea 3y ago
      >But it also goes on with multiple examples that support their approach whilst neglecting storing data as real tree 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.

tleb_ 3y ago

Then use a tree if you need a tree?

coldtea 3y ago

>But what do you do if the child needs to refer to the parent, or the parent needs to know its children. 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/".