[dale_glass]

Yeah, but you don't want to use that as a primary key for your stock database.

It'll work fine until you find you want to keep track of U-235 and U-238 separately.

What constitutes identity is context-dependent. Yeah, on one level they're the same thing. On another they aren't.

[rzzzt]

Make it a composite key of atomic and mass numbers, then.

[c00lio]

But then you'd miss on crystal structure to distinguish your diamonds from your coal.

[OJFord]

Which single element are they then?

Surely such a system would have a products table with something like nominal element fk, purity, mass columns anyway. (And stock table with fk to products.)

Then nothing wrong with 'natural' key on the elements, but sure, products are the thing you've (personally) made up, so of course there's no 'someone else's' key to use.

[TRiG_Ireland]

Diamonds and coal are both pure carbon (mostly carbon-12). So is graphite, and buckminsterfullerene, and a number of other things. Crystal structure matters a lot.

[OJFord]

They're not pure carbon was my point. I wasn't saying crystal structure not important, I missed that but it'd be in my 'product derived from element x' table.

[xmcqdpt2]

But then you need to have a stored procedure to maintain integrity every time an atom undergoes radioactive decay, that's got to be bad for performance!

[alexvoda]

Actually, in that case that would not be a properly normalized key because the mass number (counts both protons and neutrons) depends on the atomic number(protons).

Also it gets fun if you want to store anti-particles too.