4 ms·

> Permanent identifiers should not carry data. I think you're attacking a straw man. The article doesn't say "instead of UUIDv4 primary keys, use keys such as

> Permanent identifiers should not carry data. I think you're attacking a straw man. The article doesn't say "instead of UUIDv4 primary keys, use keys such as birthdays with exposed semantic meaning". On the contrary, they have a section about how to use sequence numbers internally but obfuscated keys externally. (Although I agree with dfox's and formerly_proven's comments [1, 2] that XOR method they proposed for this is terrible. Reuse of a one-time pad is probably the most basic textbook example of bad cryptography. They referred to the values as "obfuscated" so they probably know this. They should have just gone with a better method instead.) [1] https://news.ycombinator.com/item?id=46272985 https://news.ycombinator.com/item?id=46272985 [2] https://news.ycombinator.com/item?id=46273325 https://news.ycombinator.com/item?id=46273325

naasking 10mo ago
I don't think the objection is that it exposes semantic meaning, but that any meaningful information is contained within the key at all, eg. even a UUID that includes timestamp information about when it was generated is "bad" in a sense, as it leaks information. Unique identifiers should be opaque and inherently meaningless.
- scottlamb 10mo ago
  Your understanding is inconsistent with the examples in vintermann's comment. Using a sequence number as an internal-only surrogate key (deliberately opaqued when sent outside the bounds of the database) is not the same as sticking gender identity, birth date, or any natural properties of a book into a broadly shared identifier.
  - naasking 10mo ago
    No it's not, they very explicitly clarify in follow-up comments that unique identifiers should not be embedded any kind of meaningful content. See: https://news.ycombinator.com/item?id=46276995 https://news.ycombinator.com/item?id=46276995 https://news.ycombinator.com/item?id=46273798 https://news.ycombinator.com/item?id=46273798
    - scottlamb 10mo ago
      Okay, but they ignore the stuff I was talking about, consistent with my description of this as a straw man attack. > A running number also carries data. Before you know it, someone's relying on the ordering or counting on there not being gaps - or counting the gaps to figure out something they shouldn't. The opaquing prevents that. They also describe this as a "premature optimization". That's half-right: it's an optimization. Having the data to support an optimization, and focusing on optimizing things that are hard to migrate later, is not premature.
patmorgan23 10mo ago
Insert order or time is information. And if you depend on that information you are going to be really disappointed when back dated records have to be inserted.
- scottlamb 10mo ago
  Right, to ensure your clients don't depend on that information, make the key opaque outside the database through methods such as the ones dfox and formerly_proven suggested, as I said.

naasking 10mo ago

I don't think the objection is that it exposes semantic meaning, but that any meaningful information is contained within the key at all, eg. even a UUID that includes timestamp information about when it was generated is "bad" in a sense, as it leaks information. Unique identifiers should be opaque and inherently meaningless.

scottlamb 10mo ago
Your understanding is inconsistent with the examples in vintermann's comment. Using a sequence number as an internal-only surrogate key (deliberately opaqued when sent outside the bounds of the database) is not the same as sticking gender identity, birth date, or any natural properties of a book into a broadly shared identifier.
- naasking 10mo ago
  No it's not, they very explicitly clarify in follow-up comments that unique identifiers should not be embedded any kind of meaningful content. See: https://news.ycombinator.com/item?id=46276995 https://news.ycombinator.com/item?id=46276995 https://news.ycombinator.com/item?id=46273798 https://news.ycombinator.com/item?id=46273798
  - scottlamb 10mo ago
    Okay, but they ignore the stuff I was talking about, consistent with my description of this as a straw man attack. > A running number also carries data. Before you know it, someone's relying on the ordering or counting on there not being gaps - or counting the gaps to figure out something they shouldn't. The opaquing prevents that. They also describe this as a "premature optimization". That's half-right: it's an optimization. Having the data to support an optimization, and focusing on optimizing things that are hard to migrate later, is not premature.

patmorgan23 10mo ago

Insert order or time is information. And if you depend on that information you are going to be really disappointed when back dated records have to be inserted.

scottlamb 10mo ago
Right, to ensure your clients don't depend on that information, make the key opaque outside the database through methods such as the ones dfox and formerly_proven suggested, as I said.