
Do you really need a UUID/GUID? - vikeri
https://rclayton.silvrback.com/do-you-really-need-a-uuid-guid
======
JoeAltmaier
With UUIDs for keys, you can shard your database, then later merge or migrate
parts with no issues about collision or reindexing. That's useful. Whole
coding tasks (and whole classes of bugs) disappear entirely.

------
dozzie
> Sequential values tend to index well because they don't require large
> sections of the index to be realigned

Erm... What? I don't understand this sentence at all, and I know well how
indexing works.

> [MySQL performance] Notice the nearly consistent insertion time of a long
> integer vs. the UUID.

Oh boy. You just found out that (a) MySQL is a subpar product and (b) that
inserting 4 or 8 bytes is faster than inserting 36 bytes.

How about inserting 8 bytes (int64) vs. inserting 16 bytes (deicated UUID
type) in PostgreSQL?

> Auto incremented integers will almost always be smaller, meaning scans
> against tables/records will be more efficient.

And this is because...?

You know how B-trees work, do you? And you do know that you _very_ rarely need
a _sequential_ iteration over _artificial_ key in a database?

