3 ms·

I’d wager that nonhuman intelligences out there in the universe have analogous tables to the periodic table. And I suspect it would be possible for us to JOIN

I’d wager that nonhuman intelligences out there in the universe have analogous tables to the periodic table. And I suspect it would be possible for us to JOIN our periodic table onto theirs by matching on the atomic number field to create a mapping between, say, our names for the elements and theirs. That seems unlikely to be something we would be able to do with literally any other dataset that an alien civilization has. Their star catalog will contain many of the same objects ours does - but there won’t be an obvious key that lets us join them up. I guess there’s a few mathematical objects that would work - the list of Platonic solids maybe, or the symmetry groups… but in terms of real world physical things? Atomic numbers might be the only truly natural key there is.

dkarl 3y ago
The periodic table groups atoms by the number of protons they have and ignores other differences. Uranium 235 and Uranium 238 have the same "natural key" according to the periodic table. The periodic table is useful for solving a lot of problems, and for other problems where it doesn't work to treat U-235 and U-238 as the same, we (and other intelligences) use other ways of categorizing atoms.
- jameshart 3y ago
  Right, but there’s a reason we call them ‘isotopes of Uranium’ rather than saying U-238, Np-238 and Pu-238 are isotopes in the ‘family of atoms with atomic mass 238’. Things with 92 protons in them behave chemically in similar ways. They form the same crystals and molecules. If you were building a table of isotopes you’d put a column for ‘proton count’, and you’d find lots of the properties of the isotopes depend on the proton count not the atomic mass. So you could normalize that table structure out and create another table with the atomic number as the key, and put all the properties that are common to all isotopes of a given element in that table. You would have made a table of elements and it would have the same primary key as the periodic table. That’s what a natural key is. One that emerges naturally when you normalize data you have collected. I suppose similarly ‘electrons in outer shell’ might emerge as a natural key by that process.
  - dkarl 3y ago
    I don't think that's what people mean when they say "natural key." People say "natural key" when they're talking about a unique identifier (that's the "key" part) that is part of the domain model of an object (the "natural" part.) If we drop the "unique identifier" aspect of a key, and we can distinguish between different objects that share the same value according to one key by using a different key, then anything can be a key. The number of pages in a book could be a "natural key." This conversation wouldn't exist if that's what people meant by "natural key," because the answer would be trivial.
    - TeMPOraL 3y ago
      > If we drop the "unique identifier" aspect of a key, and we can distinguish between different objects that share the same value according to one key by using a different key, then anything can be a key. And the point the article is making, and that I was trying to emphasize further in my top-level comment, is that there are no perfectly unique identifiers. There are no UIDs in nature. UIDs do exist in human-designed systems, but they are only as good as the actual implementation of the system is, including its evolution over time. Your own surrogate keys are the most reliable UIDs, because while you can still screw those up, it's in your power to avoid the mistake, and it's also in your power to fix any problem. Once you start using as keys "UIDs" that aren't owned by you, you lose both the ability to prevent bugs and to fix them. For example, if you're making a library system and use a surrogate ID as a key, duplicates may happen - but they're always indicative of someone screwing up data entry, and can be trivially corrected by assigning a new ID for the entry. If you're using ISBN, or EAN-13, or some unholy hash of author/title/publication year, you're going to get a lot of corner cases, and you won't be able to fix them (you can't exactly change the barcode on everyone's copy of a printed book, just to undo the problems caused by the publisher playing funny games with SKUs). > People say "natural key" when they're talking about a unique identifier (that's the "key" part) that is part of the domain model of an object (the "natural" part.) Yes; under this phrasing, the point of TFA/my top comment is, your "natural key" is going to be only as good as your domain model of an object is - which, in practice, means it's going to be bad, because if your model defines some property correlated with real world to be unique, it's already broken. Ultimately, the point is: there are no truly unique keys in the real world. Best you can do is to chose a key that's least likely to be duplicated in data. Perhaps so unlikely that, in non-critical systems, you can get away pretending it's unique.

dkarl 3y ago

The periodic table groups atoms by the number of protons they have and ignores other differences. Uranium 235 and Uranium 238 have the same "natural key" according to the periodic table. The periodic table is useful for solving a lot of problems, and for other problems where it doesn't work to treat U-235 and U-238 as the same, we (and other intelligences) use other ways of categorizing atoms.

jameshart 3y ago
Right, but there’s a reason we call them ‘isotopes of Uranium’ rather than saying U-238, Np-238 and Pu-238 are isotopes in the ‘family of atoms with atomic mass 238’. Things with 92 protons in them behave chemically in similar ways. They form the same crystals and molecules. If you were building a table of isotopes you’d put a column for ‘proton count’, and you’d find lots of the properties of the isotopes depend on the proton count not the atomic mass. So you could normalize that table structure out and create another table with the atomic number as the key, and put all the properties that are common to all isotopes of a given element in that table. You would have made a table of elements and it would have the same primary key as the periodic table. That’s what a natural key is. One that emerges naturally when you normalize data you have collected. I suppose similarly ‘electrons in outer shell’ might emerge as a natural key by that process.
- dkarl 3y ago
  I don't think that's what people mean when they say "natural key." People say "natural key" when they're talking about a unique identifier (that's the "key" part) that is part of the domain model of an object (the "natural" part.) If we drop the "unique identifier" aspect of a key, and we can distinguish between different objects that share the same value according to one key by using a different key, then anything can be a key. The number of pages in a book could be a "natural key." This conversation wouldn't exist if that's what people meant by "natural key," because the answer would be trivial.
  - TeMPOraL 3y ago
    > If we drop the "unique identifier" aspect of a key, and we can distinguish between different objects that share the same value according to one key by using a different key, then anything can be a key. And the point the article is making, and that I was trying to emphasize further in my top-level comment, is that there are no perfectly unique identifiers. There are no UIDs in nature. UIDs do exist in human-designed systems, but they are only as good as the actual implementation of the system is, including its evolution over time. Your own surrogate keys are the most reliable UIDs, because while you can still screw those up, it's in your power to avoid the mistake, and it's also in your power to fix any problem. Once you start using as keys "UIDs" that aren't owned by you, you lose both the ability to prevent bugs and to fix them. For example, if you're making a library system and use a surrogate ID as a key, duplicates may happen - but they're always indicative of someone screwing up data entry, and can be trivially corrected by assigning a new ID for the entry. If you're using ISBN, or EAN-13, or some unholy hash of author/title/publication year, you're going to get a lot of corner cases, and you won't be able to fix them (you can't exactly change the barcode on everyone's copy of a printed book, just to undo the problems caused by the publisher playing funny games with SKUs). > People say "natural key" when they're talking about a unique identifier (that's the "key" part) that is part of the domain model of an object (the "natural" part.) Yes; under this phrasing, the point of TFA/my top comment is, your "natural key" is going to be only as good as your domain model of an object is - which, in practice, means it's going to be bad, because if your model defines some property correlated with real world to be unique, it's already broken. Ultimately, the point is: there are no truly unique keys in the real world. Best you can do is to chose a key that's least likely to be duplicated in data. Perhaps so unlikely that, in non-critical systems, you can get away pretending it's unique.