Guid vs INT - ¿Cuál es mejor como clave principal?

He estado leyendo sobre razones para usar o no Guidy int.

intEs más pequeño, más rápido, fácil de recordar, mantiene una secuencia cronológica. Y en cuanto a Guid, la única ventaja que encontré es que es única. ¿En qué caso a Guidsería mejor que inty por qué?

Por lo que he visto, intno tiene fallas excepto por el límite de número, que en muchos casos son irrelevantes.

¿Por qué exactamente fue Guidcreado? De hecho, creo que tiene un propósito que no sea servir como clave principal de una tabla simple. (¿Algún ejemplo de una aplicación real que use Guidpara algo?)

_{(Guid = UniqueIdentifier) ​​tipo en SQL Server}

Esto se ha pedido en Stack Overflow aquí y aquí .

La publicación de Jeff explica mucho sobre los pros y los contras del uso de GUID.

GUID Pros

• Único en cada tabla, cada base de datos y cada servidor
• Permite combinar fácilmente registros de diferentes bases de datos
• Permite una fácil distribución de bases de datos en múltiples servidores
• Puede generar ID en cualquier lugar, en lugar de tener que hacer un viaje de ida y vuelta a la base de datos
• La mayoría de los escenarios de replicación requieren columnas GUID de todos modos

Contras GUID

• Es enormemente 4 veces más grande que el valor tradicional del índice de 4 bytes; Esto puede tener serias implicaciones de rendimiento y almacenamiento si no tiene cuidado
• Incómodo de depurar ( where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Los GUID generados deben ser parcialmente secuenciales para un mejor rendimiento (por ejemplo, newsequentialid()en SQL Server 2005+) y para permitir el uso de índices agrupados

Si está seguro del rendimiento y no planea replicar o fusionar registros, utilice inty configure el incremento automático ( semilla de identidad en SQL Server ).

Si está sincronizando sus datos con una fuente externa, un GUID persistente puede ser mucho mejor. Un ejemplo rápido de dónde estamos usando un GUID es una herramienta que se envía al cliente para rastrear su red y hacer ciertas clases de autodescubrimiento, almacenar los registros encontrados y luego todos los registros del cliente se integran en una base de datos central De vuelta a nuestro lado. Si usáramos un número entero, tendríamos 7,398 "1" s, y sería mucho más difícil hacer un seguimiento de qué "1" era cuál.

He utilizado un enfoque híbrido con éxito. Las tablas contienen AMBAS idcolumnas de enteros de clave primaria de incremento automático Y una guidcolumna. Se guidpuede usar según sea necesario para identificar globalmente de manera única la fila y idse puede usar para consultas, clasificación e identificación humana de la fila.

Algunas de las mejores prácticas aún mencionan que debe usar un tipo de datos que se adapte con la menor memoria posible a todo el conjunto de valores que va a usar. Por ejemplo, si lo está utilizando para almacenar el número de empleadores en una pequeña empresa y es poco probable que llegue a 100, entonces nadie sugeriría usar un valor bigint mientras int (incluso smallint) lo haría.

Por supuesto, el inconveniente de esto es como "¡Di no a la escalabilidad!"

Además, sé que esto no está totalmente relacionado, pero hay otro factor con respecto a esto. Cuando no es excesivo, generalmente trato de recomendar el uso de una clave primaria no autogenerada, si tiene sentido. Por ejemplo, si está guardando la información del conductor, no se moleste en crear una nueva columna autogenerada para "ID", solo use el número de licencia.

Sé que esto suena muy obvio, pero veo que se olvida con bastante frecuencia.

Para el contexto: esta parte de la respuesta se abordó desde un enfoque teórico de datos, donde desea que su PK sea el único identificador de datos para un registro. La mayoría de las veces los creamos cuando ya existen, de ahí la respuesta anterior.

Sin embargo, es muy raro que pueda tener un control estricto sobre estos puntos de datos y, como tal, es posible que deba hacer correcciones o ajustes. No puedes hacer eso con las claves principales (bueno, puedes, pero puede ser un dolor).

Gracias @VahiD por las aclaraciones.

El uso de ID de incremento automático puede filtrar información sobre su actividad comercial. Si tiene una tienda y la utiliza order_idpara identificar públicamente una compra, cualquiera puede averiguar su número de ventas mensuales por simple aritmética.

Otra cosa con cómo se generan los GUID. mrdenny señaló correctamente que incluso si se usa newsequentialid (), reiniciar las instancias hace que los nuevos valores comiencen con los "agujeros" que quedaron en el procesamiento anterior. Otra cosa que afecta a los GUID "secuenciales" es la tarjeta de red. Si no recuerdo mal, el UID de la NIC se usa como parte del algoritmo GUID. Si se reemplaza una NIC, no hay garantía de que el UID sea un valor más alto para mantener el aspecto secuencial de las cosas. Tampoco estoy seguro de cómo las NIC múltiples pueden afectar la asignación de valores usando el algoritmo.

Solo un pensamiento y espero estar recordando correctamente. ¡Que tengas un gran día!

Usa ambos

Use int / Bigint para la clave principal, ya que es fácil de mantener y usar como relaciones de clave externa.

Pero vincule una columna al GUID para que cada fila también tenga una columna única