We can debate the first usage (small type for storage/cpu optimization) but the other 2 are actually good examples of natural keys! Note the quotes: > Every s

We can debate the first usage (small type for storage/cpu optimization) but the other 2 are actually good examples of natural keys! Note the quotes: > Every software project needs to represent the reality of the business he is embedded in... > Such database needs to be designed to properly reflect reality. This can’t be automated, since the semantics of the situation need to be encoded in a way that can be processed by a computer. Having the business need to share an ID, not give internal information, make some data opaque, use a 'arbitary' id to share as 'textual pointer' to the actual data, etc are valid natural keys. What is wrong is just add a surrogate key just because, when the fact is that a natural key (to the domain, the business, the requirements) is the actual answer. I discover this fact when doing sync. The moment I get rid of UUIDs and similar and instead keep data-as-natural things become MORE clear: ulid: 01H6GZ8YQJ code: A1 name: A ulid: 01H6GZ8YQK code: A1 name: A ulid: 01H6GZ8YQJL code: A1 name: A // All same, obscured by wrong key vs code: A1 name: A (ie: The actual data and what I need to model a sync is NOT the same. Is similar to how in 'git' your code is one thing that is clearly distinct to the internal git structures that encode the repo)