GUID vs INT IDENTIDAD

Question

Duplicar posibles:
How do you like your primary keys?

Soy consciente de las ventajas de usar un GUID, así como los beneficios de usar e INT como en PK una base de datos Teniendo en cuenta que un GUID es, en esencia, un INT de 128 bits y un INT normal de 32 bits, el INT es un ahorro de espacio (aunque este punto es generalmente irrelevante en la mayoría de los sistemas modernos).

Al final, ¿en qué circunstancias se vería usando un INT como PK frente a un GUID?

Answer 1

Kimberley Tripp (SQLSkills.com) tiene an article en el uso de GUID como claves principales. Ella aconseja contra eso debido a la sobrecarga innecesaria.

Answer 2

Un INT es mucho más fácil de leer cuando se depura y mucho más pequeño.

Sin embargo, utilizaría un GUID o similar como clave de licencia para un producto. Sabes que va a ser único, y sabes que no será secuencial.

Answer 3

Al comparar valores como la relación de la clave primaria a la externa, la INT será más rápida. Si las tablas están indexadas correctamente y las tablas son pequeñas, es posible que no veas mucha ralentización, pero tendrías que intentarlo para estar seguro. Las INT también son más fáciles de leer y comunicarse con otras personas. Es mucho más simple decir: "¿Puedes mirar el registro 1234?" en lugar de "¿Puedes mirar el registro 031E9502-E283-4F87-9049-CE0E5C76B658?"

Answer 4

Algunos sistemas operativos ya no generan GUID en función de las características de hardware únicas (CPUID, MAC) porque facilita el seguimiento de los usuarios (problemas de privacidad). Esto significa que la singularidad del GUID a menudo ya no es tan universal como mucha gente piensa.

Si utiliza alguna función de identificación automática de su base de datos, la base de datos podría en teoría estar absolutamente segura de que no hay duplicación.

Answer 5

Siempre pienso que PK debe ser numérico donde sea posible. No olvides tener GUID como PK probablemente significará que también se usan en otras tablas como claves antiguas, por lo que la paginación y el índice serán mayores.

Answer 6

Creo que la base de datos también es importante. Desde una perspectiva de MySQL: generalmente, cuanto menor es el tipo de datos, más rápido es el rendimiento.

parece ser cierto para int vs GUID también - http://kccoder.com/mysql/uuid-vs-int-insert-performance/

Answer 7

me gustaría utilizar GUID como PK sólo si estos límites clave de valor similar. Por ejemplo, id de usuario (los usuarios en WinNT se describen con GUID) o ID de grupo de usuarios. Otro ejemplo. Si desarrolla un sistema distribuido para la gestión de documentos y diferentes partes del sistema en diferentes lugares de todo el mundo puede crear algunos documentos. En tal caso, usaría GUID, porque garantiza que 2 documentos creados en diferentes partes del sistema distribuido no tendrían el mismo ID.

Answer 8

Para responder a su pregunta: Al final, ¿en qué circunstancias se vería usando un INT como PK frente a un GUID?

Usaría un GUID si mi sistema tuviera una versión en línea/fuera de línea que dentro de la versión fuera de línea pueda guardar datos y que los datos se transfieran nuevamente al servidor un día durante una sincronización.De esta forma, está seguro de que no tendrá la misma clave dos veces dentro de su base de datos.

Answer 9

Si los datos viven en una única base de datos (como la mayoría de los datos para las aplicaciones que escribimos en general), entonces uso un IDENTITY. Es fácil, pretende ser utilizado de esa manera, no fragmenta el índice agrupado y es más que suficiente. Te quedarás sin espacio en 2 billones de algunos registros (~ 4 billones si utilizas valores negativos), pero estarías tostado de todos modos si tuvieras tantos registros en una tabla, y luego tienes un problema de almacenamiento de datos.

Si los datos viven en múltiples bases de datos independientes o interfaces con un servicio de terceros, entonces usaré el GUID que probablemente ya se haya generado. Un buen ejemplo sería una tabla UserProfiles en la base de datos que asigna usuarios en Active Directory a sus perfiles de usuario en la aplicación a través de su objectGUID que el Directorio Activo les asignó.

Answer 10

el INT es un ahorro de espacio (aunque este punto es generalmente discutible en la mayoría de los sistemas modernos ).

Not so. Puede parecer a primera vista, pero tenga en cuenta que la clave principal de cada tabla se repetirá varias veces en la base de datos en índices y como clave externa en otras tablas. Y estará involucrado en casi cualquier consulta que contenga su tabla, y muy intensamente cuando se trate de una clave externa utilizada para una combinación.

Además, recuerde que las CPU modernas son muy, muy rápidas, pero las velocidades de RAM no se han mantenido. El comportamiento de la memoria caché se vuelve cada vez más importante. Y la mejor manera de obtener un buen comportamiento del caché es tener conjuntos de datos más pequeños. Por lo tanto, la diferencia aparentemente irrelevante entre 4 y 16 bytes bien puede dar como resultado una diferencia notable en la velocidad. No necesariamente siempre, pero es algo a considerar.

Answer 11

Si planea fusionar la base de datos en algún momento, es decir, para una configuración de tipo de replicación de sitios múltiples, Guid's ahorrará mucho daño. Pero aparte de eso, encuentro que Int es más fácil.

Answer 12

Además de ser una mala elección cuando necesita sincronizar varias instancias de base de datos, las INT tienen un inconveniente que no he mencionado: las inserciones siempre ocurren en un extremo del árbol de índice. Esto aumenta la contención de bloqueo cuando tiene una tabla con mucho movimiento (dado que las mismas páginas de índice deben ser modificadas por inserciones simultáneas, mientras que las GUID se insertarán en todo el índice). El índice también puede tener que reequilibrarse más a menudo si se usa un árbol B * o una estructura de datos similar.

Por supuesto, las int son más fáciles de ver cuando se realizan consultas manuales y se genera un informe, y el consumo de espacio puede aumentar a través de los usos de FK.

Me gustaría ver cualquier medida de qué tan e.g. SQL Server realmente maneja tablas de inserción pesadas con IDENTITY PK's.

Answer 13

Tenemos guías en nuestro muy complejo software empresarial en todas partes. Funciona sin problemas.

Creo que los Guids son semánticamente más adecuados para servir como identificadores. Tampoco tiene sentido preocuparse innecesariamente por el rendimiento hasta que se enfrente con ese problema. Cuidado con la optimización prematura.

También hay una ventaja con la migración de bases de datos de cualquier tipo. Con Guids no tendrás colisiones. Si intenta fusionar varios DB donde se usan enter para la identidad, tendrá que reemplazar sus valores. Si estos valores antiguos se usaron en las URL, ahora serán diferentes después del éxito SEO.