¿v4 o v7?
v4 son 122 bits de puro azar. El valor no dice cuándo ni dónde se creó. Encaja en identificadores que aparecen en URLs públicas, enlaces de invitación y cualquier sitio donde el orden de creación deba quedar oculto.
v7 pone una marca de tiempo en milisegundos en los primeros 48 bits y rellena el resto con azar, así que ordenar las cadenas equivale a ordenar por fecha de creación. Sirve para claves primarias, identificadores de registro y eventos, allí donde la cronología ayuda. A cambio, la hora de creación se lee desde el propio valor: si eso revela algo, vuelve a v4.
NIL es el valor de solo ceros. Funciona como marcador de “todavía nada” en una columna que no admite nulos.
Como clave primaria
Usar UUID en vez de un entero autoincremental deja que varios servidores generen claves sin coordinarse, y un identificador en una URL ya no permite adivinar las filas vecinas.
El problema es el azar de v4. Un índice B-tree rinde mejor cuando las claves nuevas caen al final; una clave v4 cae en cualquier punto del medio y parte páginas una y otra vez. Con la tabla creciendo, las escrituras se ralentizan y el índice engorda. v7 lo evita porque sus valores crecen con el tiempo y siempre se añaden al final. Para una tabla nueva, v7 es el valor por defecto sensato.
Guárdalos como BINARY(16) en MySQL o con el tipo uuid en PostgreSQL. Conservar la cadena de 36 caracteres cuesta 20 bytes extra por fila y hace más lenta cada comparación.
Sin guiones
Los guiones son una convención de presentación, no parte del valor. Nombres de archivo, códigos de cupón y algunas APIs usan la forma pegada de 32 caracteres. Las mayúsculas también son solo presentación: antes de comparar dos UUID, pásalos ambos a minúsculas.
Al generar un lote
Cuando esta herramienta produce varios v7 de una vez, mantienen el orden en que se generaron. Todo lo creado dentro del mismo milisegundo comparte marca de tiempo, lo que desordenaría la lista, así que parte del campo aleatorio se usa como contador. Copia la lista tal cual y el orden se conserva.