3 ms·
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 separat
by dale_glass 3y ago
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 3y agoMake it a composite key of atomic and mass numbers, then.
- xmcqdpt2 3y agoBut 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!
- c00lio 3y agoBut then you'd miss on crystal structure to distinguish your diamonds from your coal.
- OJFord 3y agoWhich 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 3y agoDiamonds 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 3y agoThey'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.
- alexvoda 3y agoActually, 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.