Yes, this is standard. And the point is performance. The needs of user-facing ID's (short alphanumeric, randomly ordered) tend to be pretty orthogonal to the needs of internal ID's (raw bits, monotonically increasing, maybe timestamp data).
It makes more sense to have two columns yes, one autoincrement for the primary key, and another uuidv4. Because uuids are too large and makes indexes slower
This was hard enough to enforce when it was just people writing code, and once one of those stupid incrementing integer IDs go in a public API or important codepath, it can be a real pain to rip out.
So you have a second, opaque unique identifier for the frontend to fetch? At that point why not just use a single column (UUID)?
Yes, this is standard. And the point is performance. The needs of user-facing ID's (short alphanumeric, randomly ordered) tend to be pretty orthogonal to the needs of internal ID's (raw bits, monotonically increasing, maybe timestamp data).
Yep, you'll probably join like 20 of those for each public uuid lookup. There are potential reasons not to do it this way, but it's a good default.
Higher density for indexes you use for joins. Also you can then use UUIDv4 to hide creation times if that's sensitive too.
It makes more sense to have two columns yes, one autoincrement for the primary key, and another uuidv4. Because uuids are too large and makes indexes slower
This was hard enough to enforce when it was just people writing code, and once one of those stupid incrementing integer IDs go in a public API or important codepath, it can be a real pain to rip out.