Hacker News new | ask | show | jobs
by jameshart 1122 days ago
You seem to be missing the rather important point that chemical elements are a thing. The atomic number uniquely identifies an element. There are not two distinct elements with atomic number 92 - there is one element, which we call Uranium. It has a number of isotopes (as do all elements - you can keep stuffing as many neutrons into a nucleus as your particle accelerator will let you). But Uranium is identifiably Uranium.

Sure, if I’m trying to build a table of atoms I can’t use their atomic number as a key. I would need some sort of UUID scheme. But in among all those atoms I’d find a bunch of them had stuff in common, and that that stuff is 100% correlated to each of those atoms’ atomic number.

See, the challenge here is to build a table of something where everyone can agree there is a single unambiguous natural key we can use for that thing.

And my (and OP’s) proposal is that you can do that with a table of ‘elements’ with ‘atomic number’ as the key.

You can’t do the same normalization trick with books.

Say you build a table of books with ‘title’, ‘author’, ‘publisher’, ‘year’, ‘ISBN’, ‘edition’, ‘page count’.

Are any of these - or combinations of them - actually a natural key of a common entity in disguise?

Maybe author/title/year? No. For one, I’m sure you can find distinct books that share these values. And ‘year’ is, it turns out, a synthetic key for identifying arbitrary Earth orbital cycles - not a ‘natural’ label for a time period at all. And ‘author’ names are a synthetic key too - many authors publish under multiple names (JK Rowling = Robert Galbraith) and names are just arbitrary keys assigned to specific consciousnesses embodied in particular bundles of cells for a period of years. And of course they aren’t unique, so… no good as a key anyway.

Sure you could say ‘well, I want to make “n page books” into an entity and extract that to a table but you wouldn’t find any properties you could extract out to that table - there isn’t anything that all 92 page books have in common that you could tag onto that relation.

Whereas your chemical elements table has LOTS of properties that are common to everything with each atomic number. Electron structure. What molecules it can form. What crystalline structures it forms. Sure, not its half life or its melting point, but still - useful facts that are common to all atoms with the same atomic number.

1 comments

> You seem to be missing the rather important point that chemical elements are a thing.

I fundamentally disagree with this. Elements are a human-created categorization of atoms (granting that atoms are real) by atomic number.

> Maybe author/title/year? No. For one, I’m sure you can find distinct books that share these values.

Author/title/year is very much like atomic number: extremely useful and sufficient for very many practical purposes. But when dealing with books, sometimes we need more than author/title/year, and when dealing with atoms, sometimes we need more than atomic number.

Atomic number is a natural key to the elements, because it's part of the definition of element.

This is why natural keys don't exist in nature, but can exist for things we invent: because a key uniquely identifies any member of a set. A key makes every possible distinction. When we categorize things, we select some distinctions (such as the number of protons in an atom's nucleus) and throw away others (such as the number of neutrons.) The enumeration and definition of relevant distinctions is necessary for the existence of a key. We defined the elements, and as a result of how we defined them, they have a key. When we define a book table in a database, it has a key as a consequence of how it is defined.

If we don't define the set ourselves, as our invention, it is impossible to anticipate all of the possible distinctions between members, so it is impossible to construct a key.