GUID vs IDENTIDAD INT [duplicado]

Question

  

Posible duplicado:
   ¿Cómo le gustan sus claves principales?

Conozco los beneficios de usar un GUID, así como los beneficios de usar e INT como PK en una base de datos. Teniendo en cuenta que un GUID es esencialmente un INT de 128 bits y un INT normal es de 32 bits, el INT ahorra espacio (aunque este punto generalmente es discutible en la mayoría de los sistemas modernos).

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

Answer 1

Kimberley Tripp (SQLSkills.com) tiene un artículo sobre el uso de GUID como claves principales. Ella desaconseja esto debido a la sobrecarga innecesaria.

Answer 2

Además de ser una mala elección cuando necesita sincronizar varias instancias de bases de datos, los INT tienen un inconveniente que no he visto 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 (ya que las mismas páginas de índice deben modificarse mediante inserciones concurrentes, mientras que los GUID se insertarán en todo el índice). El índice también puede tener que reequilibrarse con mayor frecuencia si se utiliza un árbol B * o una estructura de datos similar.

Por supuesto, los int son más fáciles de ver al hacer consultas manuales e informar sobre la construcción, y el consumo de espacio puede acumularse a través de los usos de FK.

Me interesaría ver cualquier medida de cuán bien, p. SQL Server realmente maneja tablas pesadas de inserción con PK de IDENTIDAD.

Answer 3

Para responder a su pregunta: Al final, ¿en qué circunstancias te verías 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 puede guardar datos y esos datos se transfieren al servidor un día durante una sincronización. De esa manera, está seguro de que no tendrá la misma clave dos veces dentro de su base de datos.

Answer 4

  

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

No es así. Puede parecerlo a primera vista, pero tenga en cuenta que la clave principal de cada tabla se repetirá varias veces en toda 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 foránea utilizada para una unió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 caché se vuelve, por lo tanto, cada vez más importante. Y la mejor manera de obtener un buen comportamiento de caché es tener conjuntos de datos más pequeños. Por lo tanto, la diferencia aparentemente irrelevante entre 4 y 16 bytes puede resultar en una diferencia notable en la velocidad. No necesariamente siempre, pero es algo a tener en cuenta.

Answer 5

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

Creo que las guías son semánticamente más adecuadas para servir como identificadores. Tampoco tiene sentido preocuparse innecesariamente por el rendimiento hasta que se enfrente a 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 varias bases de datos donde los ints se utilizan para la identidad, deberá reemplazar sus valores. Si estos valores antiguos se usaron en las URL, ahora serán diferentes después del éxito de SEO.

Answer 6

Cuando se comparan valores como la relación de clave primaria con clave externa, el INT será más rápido. Si las tablas están indexadas correctamente y las tablas son pequeñas, es posible que no vea mucha desaceleración, pero tendrá que intentarlo para asegurarse. Los 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 7

Algunos sistemas operativos ya no generan GUID basados ??en características de hardware únicas (CPUID, MAC) porque facilita el rastreo de los usuarios (preocupaciones de privacidad). Esto significa que la unicidad GUID ya no es tan universal como muchas personas piensan.

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

Answer 8

Si los datos viven en una sola base de datos (como lo hace la mayoría de los datos para las aplicaciones que escribimos en general), entonces uso un IDENTITY . Es fácil, está diseñado para usarse de esa manera, no fragmenta el índice agrupado y es más que suficiente. Te quedarás sin espacio en 2 mil millones de registros (~ 4 mil millones si usas 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 o interfaces independientes con un servicio de terceros, entonces usaré el GUID que probablemente ya se generó. Un buen ejemplo sería una tabla de UserProfiles en la base de datos que asigna a los usuarios en Active Directory a sus perfiles de usuario en la aplicación a través de su objectGUID que Active Directory les asignó.

Answer 9

Si está planeando 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 le ahorrará mucho dolor. Pero aparte de eso, encuentro que es más fácil.

Answer 10

Siempre pienso que los PK deben ser numéricos siempre que sea posible. No olvide que tener GUID como PK probablemente significará que también se usan en otras tablas como claves extranjeras, por lo que la paginación y el índice, etc. serán mayores.

Answer 11

Creo que la base de datos también importa. Desde una perspectiva MySQL, generalmente, cuanto más pequeño 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 12

Usaría GUID como PK solo si esta clave se limita a un valor similar. Por ejemplo, la identificación de usuario (los usuarios en WinNT se describen con GUID) o la identificación del 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 13

Un INT es ciertamente mucho más fácil de leer al depurar, y mucho más pequeño.

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