Sandra G.
Nivel 3 ·
Tamara I.
Nivel 3 ·
Los dos argumentos son ciertos. Un ID secuencial en una URL pública deja adivinar otros recursos y estimar tu volumen. Un UUID ocupa 16 bytes contra 8 de un BIGINT.
Alejandro
Nivel 3 ·
El problema de rendimiento es sobre todo con UUIDv4, que es totalmente aleatorio: cada inserción cae en cualquier lugar del índice B-tree y lo fragmenta. Con tablas grandes se nota.
CITLALI A.
Nivel 3 ·
Por eso se está usando cada vez más UUIDv7, que arranca con un timestamp y es ordenable. Quedó estandarizado este año en el RFC nuevo de UUID.
Daniela
Nivel 3 ·
Patrón que usamos: BIGINT autoincremental como PK interna para los JOINs, y un UUID aparte como identificador público en la API.
Ana R.
Nivel 3 ·
Ojo que 'adivinable' no es un problema de seguridad si tu API valida permisos como corresponde. Si alguien puede ver el pedido 1235 sin ser el dueño, el problema no es el ID.
Sandra G.
Nivel 3 ·
Muy buen punto el último. Creo que vamos a ir por el patrón mixto. Gracias a todos.
Alejandro
Nivel 3 ·
Si usan Postgres, guárdenlo como tipo uuid nativo, no como texto. Ocupa mucho menos y compara más rápido.