> you can absolutely make a tree-like structure in SQL in a variety of ways: adjacency lists, nested sets, closure tables, etc.
That's kinda the problem—rather there being 1 way to make a tree-like structure in SQL, that works correctly, there's a lot of ways to do it, and they all have different tradeoffs, and they're all a bit obnoxious.
And the article says that yes, you need various different looks at the same data. I would say UX is a beast, once a UX person tells me what they need SQL query comes up easily. Figuring out what they need is typically the hard part.
> once a UX person tells me what they need SQL query comes up easily. Figuring out what they need is typically the hard part.
If they needed only one thing, sure. However, often UX needs to look at the same data in very different ways, and an efficient representation for one need might not be at all efficient for the next (which may not even be known as a need for several years).
It’s a lot easier if they tell you what they need when you’re designing the schemata. Unfortunately, IME this isn’t done, and so you wind up with tons of bolted-on attributes later, throwing any hope of normalization out the window.
That's kinda the problem—rather there being 1 way to make a tree-like structure in SQL, that works correctly, there's a lot of ways to do it, and they all have different tradeoffs, and they're all a bit obnoxious.