INT vs Unique-Identificador para el campo ID en la base de datos

Los GUID son problemáticos como claves agrupadas debido a la alta aleatoriedad. Este problema fue abordado por Paul Randal en la última columna de Preguntas y respuestas de la revista Technet: Me gustaría usar un GUID como clave de índice agrupada, pero los otros argumentan que puede conducir a problemas de rendimiento con los índices. ¿Es esto cierto y, si es así, puede explicar por qué?

Ahora tenga en cuenta que la discusión se trata específicamente de índices agrupados. Dices que quieres usar la columna como 'ID', es decir no está claro si lo quiere decir como clave agrupada o solo clave primaria. Por lo general, los dos se superponen, por lo que asumiré que desea usarlo como índice agrupado. Las razones por las que es una mala elección se explican en el enlace al artículo que mencioné anteriormente.

Para los índices no agrupados, los GUID todavía tienen algunos problemas, pero no tan grandes como cuando son la clave agrupada más a la izquierda de la tabla. Una vez más, la aleatoriedad de los GUID introduce divisiones de página y fragmentación, ya sea en el nivel de índice no agrupado solo (un problema mucho menor).

Hay muchas leyendas urbanas que rodean el uso de GUID que los condenan en función de su tamaño (16 bytes) en comparación con un int (4 bytes) y prometen una horrible condena de rendimiento si se utilizan. Esto es un poco exagerado. Una clave de tamaño 16 puede ser una clave muy peformant todavía, en un modelo de datos correctamente diseñado. Si bien es cierto que ser 4 veces más grande que un int da como resultado más páginas no foliares de menor densidad en índices, esto no es una preocupación real para la gran mayoría de las mesas. La estructura del árbol b es un árbol naturalmente bien equilibrado y la profundidad del recorrido del árbol rara vez es un problema, por lo que buscar un valor basado en la clave GUID en lugar de una clave INT es similar en rendimiento. Un recorrido hoja-página (ie. un escaneo de tabla) no mira las páginas que no son hojas, y el impacto del tamaño del GUID en el tamaño de la página es típicamente bastante pequeño, ya que el registro en sí es significativamente más grande que los 12 bytes adicionales introducidos por el GUID. Así que tomaría el escuchar-decir consejo basado en 'es 16 bytes vs. 4' con un, bastante grande, grano de sal. Analice caso por caso y decida si el impacto del tamaño hace una diferencia real: cuántas otras columnas están en la tabla (es decir. cuánto impacto tiene el tamaño del GUID en las páginas de la hoja) y cuántas referencias lo están usando(es decir. cuántas otras tablas aumentarán debido al hecho de que necesitan almacenar una clave externa más grande).

Estoy llamando todos estos detalles en una especie de defensa improvisada de los GUID porque han estado recibiendo mucha mala prensa últimamente y algunos son inmerecidos. Tienen sus méritos y son indispensables en cualquier sistema distribuido (en el momento en que se habla de movimiento de datos, ya sea a través de replicación o marco de sincronización o lo que sea). He visto que se toman malas decisiones basadas en la mala reputación del GUID cuando eran rechazadas sin la debida consideración. Pero es cierto, si tiene que usar un GUID como clave agrupada, asegúrese de abordar el problema de aleatoriedad: utilice guid secuenciales cuando sea posible.

Y finalmente, para responder a tu pregunta: si no tienes una razón específica para usar GUIDs, usa INTs.