The article explicitly argues against the use of GUIDs as primary keys, and I'm arguing for it.
A running number also carries data. Before you know it, someone's relying on the ordering or counting on there not being gaps - or counting the gaps to figure out something they shouldn't.
> The article explicitly argues against the use of GUIDs as primary keys, and I'm arguing for it.
Let's clarify things.
The author argues against UUIDv4 as primary keys when compared to integers or bigints in large databases for performance reasons.
The examples you give refer to the common mistake of using a non-unique attribute that can be changed for a given entity as a primary key.
>Before you know it, someone's relying
Do not expose your internal IDs. As simple as that.
> A running number also carries data. Before you know it, someone's relying on the ordering or counting on there not being gaps - or counting the gaps to figure out something they shouldn't.
For example, if https://github.com/pytorch/pytorch/issues/111111 can be seen but https://github.com/pytorch/pytorch/issues/111110 can't, someone might infer the existence of a hidden issue relating to a critical security problem.
Whereas if the URL was instead https://github.com/pytorch/pytorch/issues/761500e0-0070-4c0d... that risk would be avoided.