Hacker News Reader

Comment by ramijames | Hacker News Reader

The problem here is that most often the value in the structure is the hierarchy of the data and NOT the displayed tree. You will want to do stuff with the data like traverse it, show relationships, reorder it, etc.

IMO, it's a dangerous thing to hold VISUAL information in a data structure in a database. Seems shortsighted.

View on HN

It's kind of a strange response when the author already explicitly said "people think they always need to formally encode parent-child relationships but sometimes they don't, sometimes nested display is all that's needed".

What's the response here? "No, that can't possibly be true"?

You Aren't Gonna Need It is a celebrated building heuristic for a reason. You Should Always Assume You Need It simply isn't true.

You're Gonna Write A Migration For This When the PM Asks For Batch Operations On Subtrees isn't as catchy, I suppose.

I worked with some YAGNI zealots and this was a routine experience. I adopted the philosophy of IYHTAYPGNI, "If You Have To Ask, You're Probably Gonna Need It".

Will you really need a migration for that? OP's storage is already in depth-first order, so subtrees are easy to fetch.

Exactly this. You plan around what might be needed in the future. I've found some extra work now is usually a lot less work in the future.

There's YAGNI and then there's Suitable for Purpose. If you display a thing like a tree, then people are going to expect to do tree-like things to it, like collapse views and reorder items. You might as well just git gud at tree operations and save yourself the hassle once and for all of chasing down edge cases every time a new feature request comes in for things that should have been natural extensions but you omitted "cuz YAGNI".

Just because something has a tree structure, it needs to be able to support all tree operations? Why is that such a compelling argument to you? What if it just doesn't?

It’s more like: if something has a tree structure, and the project scope is not 100% finalized, then more likely then not tree operations are going to eventually be requested. The cost savings from the hack is so low versus a standard tree representation that it’s unlikely to be worth the risk this occurs

The cost savings is low but the risk is high? How do you figure? It sounds like both options are easy (one is just even easier) so there's not much risk if we have to switch.

The thing is, once you learn how to do tree operations, they aren't that hard to do.

I'm not talking about learning how to balance a binary tree in the most efficient way possible. I'm talking about the basic ops of breadth- and depth-first traversals of arbitrary trees.

I feel like we live in an era of software development that took a stupid meme about "inverting a binary tree" as a job interview question and--not knowing anything about trees--turned it into received wisdom that "trees are hard".

But they just aren't. And yet so many people live in fear of them and go to great lengths to avoid having to learn how to use them.

The irony is that they're still using parent IDs in their data. Instead of storing it in a dedicated column with an optimized data type, it's being prepended to the data string. It might not be a number, and it might not be in an ID column, but it remains an identifier that points to another (expected) value. The change of format doesn't disqualify it from being a parent ID.

Exactly. What happens if "banana" gets deleted from the database, but not "banana.eat"?

You should be able to easily reconstruct the parent/child relationships from the OP's order/indent encoding scheme though (at least if you ensured that only "valid" indents are stored, no child without a parent, etc)

So I think the easiest way would be to store as order/indent first and later migrate to parent/child when you implement features that need it.

The only change I'd do is to define "indent" more abstractly as the item's depth in the tree and not literally the number of spaces you want to render. That makes it a lot easier to spot invalid data, makes later migration easier - and also gives you more UI flexibility, because it allows you to change the rendering method or make it configurable per user (nested <ul>'s/<ol>'s, tabs, 8 spaces, 4 spaces, 1 space, etc)

If you have a data structure like...

    struct item_t {
       char key[255];
       char display_value[255];
    }

And your key has consistent path separators like a/b/c

Then looking up parents and children is incredibly easy. At worst it's a linear scan of the array, but if it's in order you can even just look at previous items in the list until you're at the parent.

Strongly agree. Denormalizing data can sometimes be a good idea, but I don't consider this to be a reasonable justification.

I have recently been faced with a challenge where I need to arrange the top level hierarchy in descending order while simultaneously arranging the second level hierarchy in ascending order with using such structure.

Reply on news.ycombinator.com