So you have a second, opaque unique identifier for the frontend to fetch? At that point why not just use a single column (UUID)?

▲

crazygringo a day ago | parent | next [-]

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).

	▲	mahboi a day ago \| parent [-]
		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.

▲

ndriscoll a day ago | parent | prev | next [-]

Higher density for indexes you use for joins. Also you can then use UUIDv4 to hide creation times if that's sensitive too.

	▲	a day ago \| parent [-]
		[deleted]

▲

nextaccountic a day ago | parent | prev [-]

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

▲

spixy 11 hours ago | parent [-]

So when public APIs use uuidv4 to fetch item, those uuidv4 still need to be indexed...

	▲	mahboi 2 hours ago \| parent [-]
		Right, but that's one lookup vs the many joins you're probably doing internally