undefined | Better HN

0 pointsscott1133418y ago0 comments

> UUIDs are way more painful than serials to recognise, remember, input or transmit...

Completely agree, but I've found this can be a non-technical "feature" too. Serial integer primary keys are much more susceptible to human error when doing any sort of direct database manipulation.

Make a typo on a integer PK? Wrong user gets deleted. UUID typo? Row not found (almost certainly).

Another source of error I've seen is when someone in sales asks "Hey, can you remove User #1234?", but they really meant Customer #1234." With UUIDs, there's no "collision" between the tables.

Clearly there are better process/tool-based ways to prevent these types of mistakes, but it's a useful side effect of UUIDs.

0 comments

3 comments · 1 top-level

tscs378y ago· 2 in thread

You can somewhat mitigate the typo problem with integers by encoding them to the outside with parity included.

An 8 bit parity should be able to easily tell any possible typo in a 32 or 64bit integer and even correct errors. You could even put the parity into the lowest 8 bit of the integer.

I'm currently working on this for a project of mine to not only prevent typos but tolerate them by using the parity and using letters that are far apart on my QWERTZ keyboard (bit local but it should work for most keyboard sets and I have parity to fall back on)

th3sly8y ago

check uuid_to_bin: https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functi...

tscs378y ago

Yes but that's a full UUID, using a 64bit integer with some encoding is far shorter.

j / k navigate · click thread line to collapse