Un GUID de 128 bits (uniqueidentifier ) la clave es, por supuesto, 4 veces más grande que un int de 32 bits llave. Sin embargo, hay algunas ventajas clave:
- No hay problema de "INSERCIÓN DE IDENTIDAD" al fusionar contenido
- Si usa un valor COMB en lugar de NEWSEQUENTIALID(), obtiene una marca de tiempo INSERT "gratuita". Incluso puedes
SELECTde la clave principal en función de un rango de fecha/hora si lo desea con algunosCAST()sofisticados llamadas. - Son únicos en todo el mundo, lo que resulta muy útil de vez en cuando.
- Dado que no es necesario realizar un seguimiento de las marcas de agua, su capa BL puede asignar el valor en lugar de SQL Server, eliminando así el paso de
SELECT scope_identity()para obtener la clave principal después de una inserción. - Si es remotamente posible que pueda tener más de 2 mil millones de registros, deberá usar
bigint(64 bits) en lugar deint. Una vez que haga eso,uniqueidentifieres solo el doble de grande que unbigint. - El uso de GUID hace que sea más seguro exponer claves en URL, etc. sin exponerse a ataques de "adivina la ID".
- Entre cómo SQL Server carga páginas desde el disco y cómo los procesadores ahora son en su mayoría de 64 bits, el hecho de que un número sea de 128 bits en lugar de 32 no significa que la comparación tarde 4 veces más. La última prueba que vi mostró que los GUID son casi tan rápidos.
- El tamaño del índice depende de cuántos Se incluyen columnas. Aunque los GUID en sí mismos son más grandes, los 8 o 12 bytes adicionales pueden ser insignificantes en comparación con las otras columnas del índice.
Al final, es posible que no valga la pena perder las ventajas de un GUID para obtener una pequeña ventaja de rendimiento mediante el uso de números enteros. Pruébalo empíricamente y decide por ti mismo.
Personalmente, sigo usando ambos, dependiendo de la situación, pero el factor decisivo nunca se ha reducido al rendimiento en mi caso.
