¿Porqué usar Primary Key extensas?

[Javatillo]

Normalmente las llaves primarias se las toma como auto numérico ,la combinación de 2 llaves extranjeras o en último caso algún varchar por ahi que identifique a la persona como única.
Pero revisando un base datos que me pasaron, me encuentro con llaves primarias enormes:

84229c58-0ab1-3835-a88a-5987b9ef7f22

Tiene dígitos hexadecimales que forman : 8-4-4-4-12 es llave primaria y es única, he aquí mi duda:

¿Porqué utilizar conbinaciónes tan grandes?
¿Porqué separar los dígitos en todas las tablas de esta forma?

lo primero que se me viene a la mente es por seguridad ya que esto esta expuesto al publico, pero ¿porqué tan enorme?, la cantidad de recursos que consume el sistema para generar esta llave es bastante.

Bueno en fin, agradezco sus comentarios de antemano.
Gracias....

[gnzsoloyo]

Esto:

84229c58-0ab1-3835-a88a-5987b9ef7f22

No es solamente una PK. Es una PK obtenida con la función UUID(), la cual:

Retorna un Universal Unique Identifier (UUID) (Identificador Único Universal) generado según la “DCE 1.1: Remote Procedure Call” (Apéndice A) CAE (Common Applications Environment) Especificaciones publicadas por The Open Group en Octubre 1997 (Número de Documento C706).

Se designa un UUID como número que es único globalmente en espacio y tiempo. Dos llamadas a UUID() generan dos valores distintos, incluso si estas llamadas se realizan en dos máquinas separadas y no están conectadas entre ellas.

(Extraído del Manual de Referencia de MySQL).

Como verás, quienes hayan creado esa tabla con tal PK es porque deseaban un identificador que fuese absolutamente imposible de repetir, bajo ninguna circunstancia. El por qué deseaban eso, es una cuestión de diseño o de seguridad.

Continuando con el MR:

Un UUID es un número de 128 bits representado por una cadena de cinco números hexadecimales en formato aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:

- Los primeros tres números se generan de un valor temporal.
- El cuarto número preserva unicidad temporal en caso de que el valor temporal pierda moniticidad (por ejemplo, debido al cambio horario).
- El quinto número es un número IEEE 802 de nodo que proporciona unicidad espacial. Un número aleatorio se sustituye si el último no está disponible (por ejemplo, debido a que la máquina no tenga tarjeta Ethernet, o no sabemos encontrar la dirección hardware de una interfaz en el sistema operativo). En este caso, la unicidad espacial no se puede garantizar. Sin embargo, una colisión debe tener una probabilidad muy baja.

Actualmente, la dirección MAC de una interfaz se tiene en cuenta sólo en FreeBSD y Linux. En otros sistemas operativos, MySQL usa un número generado aleatoriamente de 48 bits.

[Javatillo]

Muchas gracias gnzsoloyo, muy interesante la explicación, y en el manual dice todo, jeje ni se me ocurrio mirarlo.
Habia escucha de este tipo de operaciones pero solo para la función rnd().

Muy buen comentario.

[quimfv]

Solo agregar que el Identificador Único Universal se usa para trabajar con replicas de la base de datos.

Es decir copias de la bbdd que trabajan simultáneamente y sin conexión entre ellas. Mediante un proceso llamado de sincronización se consigue que las replicas, copias, vuelvan a ser idénticas aplicando las transacciones que se han ejecutado por separado de manera consistente. Es decir la bbdd conserva su coherencia aún que se modifique en copias separadas... Esto permite trabajar sobre la bbdd en entornos sin conexión permanente, obviamente en algún momento deben conectarse las distintas replicas para poder aplicar el proceso de sincronización.

De la explicación de gnzsoloyo se desprende o intuye como puede funcionar el proceso de sincronización, ya que se dispone de un identificador único globalmente en espacio y tiempo, es decir se puede comparar donde y cuando se han generado los registros...

No tengo experiencia en bbdd gestionadas de esta manera pero supongo que tendrá sus limitaciones...

Quim

[Javatillo]

bbdd Gestionadas!
Bueno... tendré que pornerme las pilas, gracias por la ayuda.