Claves primarias: IDs versus GUIDs

Los lectores más antiguos de este blog (www.codinghorror.com) saben que tengo una desmesurada debilidad por los GUID. Cada globalmente único ID es como un precioso copo de nieve: cada uno un objeto único esperando el momento de su nacimiento.

Quizás este es el motivo por el cual leo con gran interés cuentas recientes de gente cambiando las tablas de sus bases de datos de las tradicionales claves primarias enteras …

ID  Value
--  -----
1  Apple
2  Orange
3  Pear
4  Mango

… a claves GUID.

ID                                    Value
------------------------------------  -----
C87FC84A-EE47-47EE-842C-29E969AC5131  Apple
2A734AE4-E0EF-4D77-9F84-51A8365AC5A0  Orange
70E2E8DE-500E-4630-B3CB-166131D35C21  Pear
15ED815C-921C-4011-8667-7158982951EA  Mango

Sé lo que estáis pensando. Usar dieciséis bytes en lugar de cuatro para una clave primaria? Estás loco? Esos 12 bytes adicionales tienen un coste. Pero ese coste podría no ser tan grande como piensas:

• The Cost of GUIDs as Primary Keys (SQL Server 2000)


• Myths, GUID vs. Autoincrement (MySQL 5)

Usar un GUID como valor identidad de un registro es más natural –y ciertamente más verdaderamente único—que un entero de 32 bits. El gurú de las bases de datos Joe Celko parece estar de acuerdo. Las claves primarias GUID son la solución natural para muchos escenarios de desarrollo, tales como replicación, o cuando necesitas generar claves primarias fuera de la base de datos. No obstante es una cuestión de comparar los pros y los contras entre los IDs tradicionales de 4 bytes y GUIDs de 16 bytes:

GUID Pros

GUID Contras

Únicos en cada tabla, cada base de datos, cada servidor. Facilita la combinación de registros procedentes de diferentes bases de datos. Facilita la distribución de bases de datos entre múltiples servidores. Puedes generar identificadores en cualquier lugar sin necesidad de consultar la base de datos. La mayoria de escenarios de replicación requieren columnas de tipo GUID.

Es cuatro veces más pesado que el valor tradicional de 4 bytes; esto puede tener serias implicaciones en cuando a rendimiento y almacenamiento si no eres cuidadoso. Incómodo de depurar (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}') Los GUID generados deben ser parcialmente secuenciales para un rendimiento óptimo (por ejemplo, newsequentialid() en SQL 2005) y para permitir el uso índices en cluster.

No estoy proponiendo que cada base de datos cambie a claves primarias GUID, pero pienso que es importante saber que esa opción existe. Si todavía tienes dudas, what should i choose for my primary key? Contiene excelentes consejos y un sólido análisis de beneficios e inconvenientes.

Texto original de Jeff Atwood