4 ms·
Human readable IDs make sense in a lot of places. Like if a customer wants information about their order or looking up a user in a system. It's easier to say
by treis 6y ago
Human readable IDs make sense in a lot of places. Like if a customer wants information about their order or looking up a user in a system. It's easier to say and understand words than a long string of letters and numbers.
- formerly_proven 6y agoI think in many instances it would make more sense to still use nominal identifiers, but enrich them with semantic data. For example, instead of invoice #306889086579, use an ID like R2020-06-14951.
- treis 6y agoDoing that loses the benefits of UUIDs. You can get duplicate IDs and they can be guessable.
- Sohcahtoa82 6y agoDuplicate IDs shouldn't happen unless you have a bug. Them being guessable shouldn't be an issue if you have proper access controls. ...which means that not being random opens you up to potential bugs and security issues... I think I changed my own mind while typing this and I agree with you.
- treis 6y ago> Duplicate IDs shouldn't happen unless you have a bug. One of the benefits of UUIDs is that you don't have to check for duplicate IDs since the chance of generating the same UUID twice is effectively 0. If you use a system with less randomness then you do have to implement a duplicate check. Which isn't practical when you're working at large scale.
- chris_wot 6y agoIn other words, a synthetic key. Bad move.
- formerly_proven 6y agoYou mean a partially natural key, because UUIDs are as synthetic as it gets, and aren't exactly unproblematic for databases.
- pkulak 6y agoI'm a big believer that primary keys shouldn't be exposed to users. Make a secondary key with 1/4 the entropy if your users are going to need to see something. And then when you show _that_ to your users, encode it with Crockford base-32.
- debdut 6y agowill create a much easier version with 32 bit diluted entropy, thanks