3 ms·
My go-to pattern for many years now is to use a plain bigint autoincrement column for internal database relations and then a uuid for application-level identifi
by VWWHFSfQ 3y ago
My go-to pattern for many years now is to use a plain bigint autoincrement column for internal database relations and then a uuid for application-level identifiers and natural keys. Basically never use the uuid as the actual primary key because they're enormous and now the DBMS has to copy that gigantic number to every side of the relation. Don't do it
- zzzeek 3y agoSame, I'm surprised nobody is mentioning this. All the foreign key columns become uuids also and the DB becomes miserable to deal with.
- sumtechguy 3y agoThis is a good answer. You want your primary/cluster key to usually be something that makes sense in your data. If you use something like UUID the placement can be basically random. That is usually in SQL is not a desirable trait. If you use it for a primary key you are basically saying you are fine with a memory cmp vs a register compare for you finding the right data. That can be undesirable too. UUIDs do have very desirable traits such as uniqueness. But that does come at a cost and usually you can fix that by deciding what process decides the source of truth in a different way.