Hacker News Reader

Which goes to show that we often conflate identification and classification because it's convenient. It's not always the best decision longer term but it may be good enough.

For your particular task, you could have chosen to identify things of interest and assign them an ID. Separately, you could have made (and revised) a decision on whether a particular thing is a lab or a research institute and/or some other kind of entity.

In my experience, organisations are some of the most difficult things to model. The ways in which they can merge, split, be part of one another, be the same and not the same in different jurisdictions or according to different sets of rules are basically infinite.

So when you say "The really key thing with this is to identify what your database/Id is solving and what it is not" I totally agree. But I would add that identification and classification solve overlapping problems that are often deceptively similar but not quite the same.

> For your particular task, you could have chosen to identify things of interest and assign them an ID. Separately, you could have made (and revised) a decision on whether a particular thing is a lab or a research institute and/or some other kind of entity.

I get the point but we couldn't. The very concept of what one thing is, is a fuzzy decision in itself. There's also not a single hierarchy that makes sense for different uses so you can't just group and then classify - legal ownership, financing and operational control can all be distinct structures. Then how people actually work can be another.

Even then, fundamentally what we needed was to get away from trying to model the world then work out how to use it. Because then you have one Id that maps one way for one user and another for another user and now their work is incompatible - but in a subtle and hidden way.

Edit - this doesn't take away from your point, classification is a distinct problem.

The really key thing with this is to identify what your database/Id is solving and what it is not.

That's the money quote. If the indirection of long, composite, maybe changing foreign keys could be managed by the system, natural keys would be the way to go. But that doesn't happen.

> They’re all arbitrary, unnatural, human inventions

That part from the article is the weaker point. Semantics. "Natural" only means that it comes from the problem domain, it doesn't really matter.

> The really key thing with this is to identify what your database/Id is solving and what it is not.

On this context, it is very simple and straight-forward. It also generalizes almost completely.

Your database id is solving the problem of creating/managing the relationships within your data. This generalizes to basically everybody because "database id" is a concept created within a mathematical theory exactly and exclusively for that purpose.

If you try to add more purposes for it, you will get conflicting requirements.

4'33" isn't a song either. If you call a tail a leg, a dog still has 4 legs.

For a whole bunch of useful definitions and use cases, it's a song. Arguing about the precise delineations of song/not song is missing my point.

> If you call a tail a leg, a dog still has 4 legs.

I can't think of a useful definition of legs that includes the tail. I can for calling a recording of a musical piece a song.

Since we're going into this meta-philosophical thing, your statement is false. If I call a tail a leg, dogs definitely have five legs. Unless they were of course born without a leg, or have otherwise lost one. There is no "reality" from a human perspective, it's all sensory input that goes through a lot of very subjective processing.

You can't _really_ categorize things. You can mostly sort of do it, but it never actually works out, because categories are human stuff, and human stuff is subjective and thus different depending on who you ask. Sometimes unclear even to the same person.

I can say dogs have five legs and the only reason most people will think I'm wrong is that society has come to categorize limbs based on function instead of length.

Getting a little pedantic 2. a large branch of a tree. "the bare limbs of a high tree" Similar: branch

limb (n.2) late 14c., "edge of a quadrant or other instrument," from Latin limbus "ornamental border, hem, fringe, edge," a word of uncertain origin.

Just thought of the limbic system and how that might be related, doesn't seem to be about function but about positioning against a core system

My point was that categorizing limbs (differentiating them from one another) is done by function. Now that I think about it limb isn't what I had in mind anyway, what I meant to say was that we categorize parts of the body in terms of function.

But you're right, limbs are not defined by function.

In real life dogs can exist with more or less than 4 legs.

Yes! The existence of a five-legged dog makes “all dogs have four legs” false but it doesn’t make “dogs have four legs” false. Similarly, the existence of a two-legged dog makes “some dogs have only two legs” true while “dogs have two legs” is still not (unless you just mean the former).

Dog is a categorical abstraction over individuals. The properties of a category tend to have a complex relationship to the members of the category. This is true even if it is indisputable who the members are and what properties the members have.

So in OP’s example of tracking every song, if I want/need 4’33” in my database of all songs, but I need to keep track of whether cwillu think’s it’s a song for some reason (they seem pretty authoritative, better make note of it), I could create a foreign key for that and set it to values like “cwillu said it’s a song”, “cwillu said it’s NOT a song”, and “cwillu has not specified if it’s a song yet”. That’s why natural keys don’t exist.