7 ms·

> First rule of database design: Your unique IDs should not have a real-world meaning. Well, this is an opinion. I would definitely push back on making it a r

by mulmen 5y ago

> First rule of database design: Your unique IDs should not have a real-world meaning. Well, this is an opinion. I would definitely push back on making it a rule. Especially the first one. Natural keys exist, make perfectly good unique identifiers, and have inherent meaning. When using synthetic keys it is difficult (read: requires making trade-offs) to guarantee they were created in order and/or that they increase monotonically. But if you make those trade-offs (or just align expectations) you can still associate real world meaning to them. These new UUIDs standardize more of those trade-offs.

tialaramex 5y ago
> Natural keys exist, make perfectly good unique identifiers, and have inherent meaning. Most of the "natural" things you think are going to be good Primary Keys aren't. You quickly get into one of those "Falsehoods Programmers Believe About X" lists. I remember some years ago running into the Experian team who were designing a system to uniquely identify people and they'd got it all figured out for the US market. See, Americans have Social Security Numbers, so you can just use those to key off. Alas, as hopefully anybody here who actually deals with Social Security Numbers knows, they aren't unique. Perhaps you could argue they should be unique, but that's not useful in practice, because in practice they aren't. They seemed really disappointed about that. I doubt they fixed it though. It's far more likely that the "definitely unique" Natural key for your table isn't actually unique than that there will be an insurmountable problem caused by using artificial row IDs, UUIDs or something like that.
- deleted 5y ago
  [deleted]
- rkagerer 5y ago
  SSN is a terrible key (and given privacy and security concerns should probably be encrypted or otherwise peotected in any case, not showing up in logs, developers notes while troubleshooting, etc). Product serial number might be a better example. Or file hash.
  - tialaramex 5y ago
    > Product serial number might be a better example. Nope. The "serial number" is just whatever you printed on the box or maybe on the product itself. You may intend that to be unique but you've got no way to ensure that. If you tell the people in manufacturing that if any duplicates occur it's a show stopper they will tell you to stop being stupid and design your IT systems to cope with the real world. I buy serial-numbered LED lamps, the manufacturer replaces them if they drop dead within a certain number of years and I have some applications (18 hours per day of lighting) where that's plausible, so I need to track those serial numbers. Except they once shipped me a lamp (one in a box purchased together with others) with no serial number. Completely blank, no manufacturer, no type identifier, no voltage, the entire label was just missing from the product as shipped. Emailed them. No problem, apologies for the defect, your warranty registration for a lamp with no serial number will be fine.
    - staticassertion 5y ago
      I mean, they said "might be", and they're entirely correct about SSN. > Emailed them. No problem, apologies for the defect, your warranty registration for a lamp with no serial number will be fine. Seems fine?
    - michaelt 5y ago
      > If you tell the people in manufacturing that if any duplicates occur it's a show stopper they will tell you to stop being stupid and design your IT systems to cope with the real world. You've got a pretty low opinion of people in manufacturing there, buddy. No manufacturer I've ever worked with would even blink at a requirement for unique serial numbers.
      - tialaramex 5y ago
        > No manufacturer I've ever worked with would even blink at a requirement for unique serial numbers. It's easy and even expected to have a requirement. There's a requirement that US SSNs are unique too. A requirement doesn't cut it. The requirement is going to fail sooner or later and what then? How much did the manufacturers you worked with indemnify you against the consequences of non-unique serial numbers? That's what we're getting at here. When it breaks somebody has to fix it. Or, you could design it not to break. It's a man's laws versus nature's laws problem. Did you know you can pick up the soccer ball, and just carry it over the goal line? Yeah, that's "against the rules" but you can do it anyway, being against the rules doesn't make it impossible. Now, contrariwise you can't teleport the ball - doesn't matter whether the rules allow it, can't do it anyway. Nature's law are facts. Design your database to rely on facts, not man's laws as much as possible.
- _moof 5y ago
  SSNs can also change. Never, ever, ever try to use SSN as a primary key or anything even remotely like a primary key.
PostThisTooFast 5y ago
But these standards assume that the proximity of records' creation time is somehow useful for sorting them. Why? If I'm doing data entry of magazine-subscription cards (because apparently it's 1985), Mr. Warren Zelkirk might have sent his card in before Anne Ackerman. How does sorting by record-creation time help me here? Keys are useful for distinguishing records unambiguously. You typically SORT records by other columns.
williamdclt 5y ago
> Natural keys exist They probably do, but everytime I thought something was good as a natural key, I've been wrong
- phkahler 5y ago
  Agreed. The simplest example is names. People don't have unique names so you combine it with some other stuff (birthdate, SSN) and call it a primary key. Then someone gets married and changes their name. To anyone doing this for a short amount of time this example is obvious. The point is that almost everything you might think of as a "natural key" is not good enough and you'll get burned when you find out what the reasons are.
  - deleted 5y ago
    [deleted]

by mulmen 5y ago

tialaramex 5y ago

> Natural keys exist, make perfectly good unique identifiers, and have inherent meaning. Most of the "natural" things you think are going to be good Primary Keys aren't. You quickly get into one of those "Falsehoods Programmers Believe About X" lists. I remember some years ago running into the Experian team who were designing a system to uniquely identify people and they'd got it all figured out for the US market. See, Americans have Social Security Numbers, so you can just use those to key off. Alas, as hopefully anybody here who actually deals with Social Security Numbers knows, they aren't unique. Perhaps you could argue they should be unique, but that's not useful in practice, because in practice they aren't. They seemed really disappointed about that. I doubt they fixed it though. It's far more likely that the "definitely unique" Natural key for your table isn't actually unique than that there will be an insurmountable problem caused by using artificial row IDs, UUIDs or something like that.

deleted 5y ago
[deleted]
rkagerer 5y ago
SSN is a terrible key (and given privacy and security concerns should probably be encrypted or otherwise peotected in any case, not showing up in logs, developers notes while troubleshooting, etc). Product serial number might be a better example. Or file hash.
- tialaramex 5y ago
  > Product serial number might be a better example. Nope. The "serial number" is just whatever you printed on the box or maybe on the product itself. You may intend that to be unique but you've got no way to ensure that. If you tell the people in manufacturing that if any duplicates occur it's a show stopper they will tell you to stop being stupid and design your IT systems to cope with the real world. I buy serial-numbered LED lamps, the manufacturer replaces them if they drop dead within a certain number of years and I have some applications (18 hours per day of lighting) where that's plausible, so I need to track those serial numbers. Except they once shipped me a lamp (one in a box purchased together with others) with no serial number. Completely blank, no manufacturer, no type identifier, no voltage, the entire label was just missing from the product as shipped. Emailed them. No problem, apologies for the defect, your warranty registration for a lamp with no serial number will be fine.
  - staticassertion 5y ago
    I mean, they said "might be", and they're entirely correct about SSN. > Emailed them. No problem, apologies for the defect, your warranty registration for a lamp with no serial number will be fine. Seems fine?
  - michaelt 5y ago
    > If you tell the people in manufacturing that if any duplicates occur it's a show stopper they will tell you to stop being stupid and design your IT systems to cope with the real world. You've got a pretty low opinion of people in manufacturing there, buddy. No manufacturer I've ever worked with would even blink at a requirement for unique serial numbers.
    - tialaramex 5y ago
      > No manufacturer I've ever worked with would even blink at a requirement for unique serial numbers. It's easy and even expected to have a requirement. There's a requirement that US SSNs are unique too. A requirement doesn't cut it. The requirement is going to fail sooner or later and what then? How much did the manufacturers you worked with indemnify you against the consequences of non-unique serial numbers? That's what we're getting at here. When it breaks somebody has to fix it. Or, you could design it not to break. It's a man's laws versus nature's laws problem. Did you know you can pick up the soccer ball, and just carry it over the goal line? Yeah, that's "against the rules" but you can do it anyway, being against the rules doesn't make it impossible. Now, contrariwise you can't teleport the ball - doesn't matter whether the rules allow it, can't do it anyway. Nature's law are facts. Design your database to rely on facts, not man's laws as much as possible.
_moof 5y ago
SSNs can also change. Never, ever, ever try to use SSN as a primary key or anything even remotely like a primary key.

PostThisTooFast 5y ago

But these standards assume that the proximity of records' creation time is somehow useful for sorting them. Why? If I'm doing data entry of magazine-subscription cards (because apparently it's 1985), Mr. Warren Zelkirk might have sent his card in before Anne Ackerman. How does sorting by record-creation time help me here? Keys are useful for distinguishing records unambiguously. You typically SORT records by other columns.

williamdclt 5y ago

> Natural keys exist They probably do, but everytime I thought something was good as a natural key, I've been wrong

phkahler 5y ago
Agreed. The simplest example is names. People don't have unique names so you combine it with some other stuff (birthdate, SSN) and call it a primary key. Then someone gets married and changes their name. To anyone doing this for a short amount of time this example is obvious. The point is that almost everything you might think of as a "natural key" is not good enough and you'll get burned when you find out what the reasons are.
- deleted 5y ago
  [deleted]