I usually go for Nano Id for new projects https://github.com/ai/nanoid
+1 for nanoid, which matches what I used to implement myself as a lib function in new projects
You Don't Need UUID
111–120 of 199 posts
Re: You Don't Need UUID
#112> A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from a user’s perspective. I would challenge the premise we appear to be starting from, that the average end user cares to be dealing with any random string of numbers and digits. GUIDs work well, they’re implem…
I think a better argument is that that the identifier needs to be unambiguous in cases where e.g. an ID needs to be communicated over the phone between an end user and a customer service rep. But that is easily solved with encodings like Base58 that exclude ambiguous characters.
When the encoding relies on differentiating between lowercase and capitalized characters, you’re hitting a high level of ambiguity. Hexadecimal UUIDs don’t have this problem.
Re: You Don't Need UUID
#113> A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from an user’s perspective. The argumentation in this article is pretty poor from my experience. A UUID isn’t meant to be handled by the non-technical end user. The end user usually doesn’t and shouldn’t care about the URL. I can assure there are bigger architectural problems in your design if your user has to care about accessible intern…
Does this help see what's wrong with UUIDs in URLs? A GitHub issue URL in a parallel universe:
https://github.com/a73ba12d-1d8b-2516-3aee-4b15e563a835/e16957bf-7d7f-41f1-97f4-98c93a6c3540/issues/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6Re: You Don't Need UUID
#114Earlier quoted context omitted.
UUIDs are packed in DBs. But they tend to get misused as PKs. In common relational DBs, your PK for every table should probably be bigserial.
No, that shouldn’t be the criteria (common relational db) when deciding to use bigserial v UUID but the overall architecture and requirements of your system.
Whatever your overall requirements are, if you've already decided on a relational DB to solve them, you probably want bigserial PKs in said DB. The DBMS is optimized for that (as I've noticed in Postgres), and you don't gain anything by using UUIDs instead there. UUID in a secondary col or elsewhere in your system, that's fine.
If you have to look up by UUID from outside and have no foreign keys, UUID PKs can be faster. But that's the classic use case for a non-relational DB.
Re: You Don't Need UUID
#115> As Tom Scott shows in his video, 11 base58-encoded characters are enough for YouTube to serve content even when considering that private videos should be undiscoverable. Nitpick: Google isn't concerned about the discoverability of private videos; those can only be viewed when granted access. You're thinking of unlisted videos.
Fixed! Thanks!
Re: You Don't Need UUID
#116I wonder how Stripe generates their IDs. They look quite nice.
They use a type safe extension of UUIDv7
Here is a go implementation and explanation: https://github.com/jetpack-io/typeid
Re: You Don't Need UUID
#117It's amusing that the UUIDs are considered 'ugly' while the Amazon and YouTube IDs are not. Beauty is in the eye of the beholder. I don't find UUIDs pretty, at all, but the others are even uglier to my taste.
Yes, UUIDs are overkill for most applications. But CPUs and hard drives are, relatively speaking, cheap. Using an existing, battle-tested unique ID library implementation has advantages. The 8 bytes per record you're saving over bigserial is, for most use cases, negligible. 1,000,000 rows? You'll save 8 MB by switching away from UUIDs.
Most databases won't be that large. Use a UUID if you want; pretend you'll have Really Big Data some day if it makes you happy. Render it using a special function if the hyphens are too ugly.
Re: You Don't Need UUID
#118Pivoting to the related subject of compact textual representations of _typed_ data, check out CESR[0]. Through some careful choices of code prefixes and payload lengths that won't require Base64 padding, it provides a novel encoding scheme for JSON plus cryptographic signatures (all while enabling true concatenative composability). It is at the heart of the KERI[1][2][3], a decentralized identity management scheme, and ACDC[4], a mechanism for verified credentials.
[0] https://trustoverip.github.io/tswg-cesr-specification/draft-... [1] https://keri.one/keri-resources/ [2] https://trustoverip.github.io/tswg-keri-specification/draft-... [3] https://github.com/WebOfTrust/keripy/ [3] https://trustoverip.github.io/tswg-acdc-specification/draft-...
Re: You Don't Need UUID
#119IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable).
[0] https://github.com/jetpack-io/typeid [1] https://github.com/ulid/spec [2] https://github.com/segmentio/ksuid
Re: You Don't Need UUID
#120Everyone wanted UUIDs and we had IRIs all along...