sql - tipo - INT vs Unique-Identifier para el campo ID en la base de datos
uniqueidentifier c# (6)
Estoy creando una nueva base de datos para un sitio web usando SQL Server 2005 (posiblemente SQL Server 2008 en el futuro cercano). Como desarrollador de aplicaciones, he visto muchas bases de datos que usan un integer (o bigint , etc.) para un campo ID de una tabla que se usará para las relaciones. Pero últimamente también he visto bases de datos que usan el unique identifier ( GUID ) para un campo ID.
Mi pregunta es si uno tiene una ventaja sobre el otro? ¿Los campos integer serán más rápidos para consultar y unir, etc.?
ACTUALIZACIÓN: para dejar en claro, esto es para una clave principal en las tablas.
Úselos para la replicación, etc., no como claves principales.
- Contra: Espacio, no estrictamente monótono, divisiones de página, marcador / RID, etc.
- Para: er ...
El GUID va a ocupar más espacio y será más lento que un int, incluso si usa la función newsequentialid (). Si vas a hacer la replicación o usar el marco de sincronización, tienes que usar un guid.
INTs son 4 bytes, BIGINTs 8 bytes y GUIDS 16 bytes. Cuanto más espacio se necesita para representar los datos, más recursos se requieren para procesarlo: espacio en disco, memoria, etc. Por lo tanto, (a) son más lentos, pero (b) esto probablemente solo importa si el volumen es un problema (millones de filas, o miles de transacciones en muy, muy poco tiempo).
La ventaja de los GUID es que son (más o menos) globalmente únicos. Genere un guid utilizando el algoritmo adecuado (y SQL Server xxxx usará el algoritmo adecuado), y no habrá dos guías iguales, sin importar cuántas computadoras las haya generado, sin importar la frecuencia. (Esto no se aplica después de 72 años de uso - Olvidé los detalles).
Si necesita identificadores únicos generados en varios servidores, los GUID pueden ser útiles. Si necesita una perforación mondo y menos de 2 mil millones de valores, es probable que estén bien. Por último, y quizás lo más importante, si sus datos tienen claves naturales, quédese con ellos y olvídese de los valores sustitutos.
Los GUID son problemáticos como claves agrupadas debido a la alta aleatoriedad. Este tema fue abordado por Paul Randal en la última columna de preguntas y respuestas de Technet Magazine: me gustaría usar un GUID como la clave de índice agrupado, pero los otros argumentan que puede generar problemas de rendimiento con los índices. ¿Es esto cierto y, si es así, puedes explicar por qué?
Ahora tenga en cuenta que la discusión es específicamente sobre índices agrupados . Usted dice que quiere usar la columna como ''ID'', no está claro si la quiere decir como clave agrupada o solo como clave principal. Por lo general, los dos se superponen, así que supongo que desea usarlo como índice agrupado. Las razones por las cuales esa es una mala elección se explican en el enlace al artículo que mencioné anteriormente.
Para los índices no agrupados, los GUID aún tienen algunos problemas, pero no tan grandes como cuando son la clave agrupada más a la izquierda de la tabla. De nuevo, la aleatoriedad de los GUID introduce divisiones de páginas y fragmentación, ya sea en el nivel de índice no agrupado (un problema mucho más pequeño).
Hay muchas leyendas urbanas que rodean el uso de GUID que las condenan en función de su tamaño (16 bytes) en comparación con un int (4 bytes) y prometen una fatalidad de rendimiento horrible si se usan. Esto es ligeramente exagerado. Una clave de tamaño 16 puede ser una clave muy relevante aún, en un modelo de datos diseñado correctamente. Si bien es cierto que ser 4 veces más grande que un int resulta en páginas de hojas no hojas de menor densidad en los índices, esto no es una preocupación real para la gran mayoría de las tablas. La estructura b-tree es un árbol naturalmente equilibrado y la profundidad del recorrido de los árboles rara vez es un problema, por lo que buscar un valor basado en la clave GUID en comparación con una clave INT es similar en rendimiento. Un recorrido de hoja de página (es decir, un escaneo de tabla) no mira las páginas que no son hojas, y el impacto del tamaño de GUID en el tamaño de página suele ser bastante pequeño, ya que el registro es significativamente mayor que los 12 bytes adicionales introducidos por el GUID. Así que tomaría el consejo de escuchar y decir basado en "16 bytes vs. 4" con un grano de sal bastante grande. Analice caso por caso y decida si el impacto del tamaño hace una diferencia real: cuántas columnas hay 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 la 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 a todos estos detalles en una especie de defensa improvisada de los GUID porque últimamente han recibido mucha mala prensa y algunos no se merecen. Tienen sus ventajas y son indispensables en cualquier sistema distribuido (en el momento en que se habla de movimiento de datos, ya sea a través de la replicación o el marco de sincronización o lo que sea). He visto malas decisiones basadas en la mala reputación del GUID cuando fueron rechazadas sin la consideración adecuada. Pero es cierto, si tiene que usar un GUID como clave agrupada, asegúrese de abordar el problema de la aleatoriedad: utilice guías secuenciales cuando sea posible.
Y finalmente, para responder a su pregunta: si no tiene una razón específica para usar GUID, use INTs.
Totalmente de acuerdo con JBrooks. Quiero decir que cuando su tabla es grande y usa selects con JOINS, especialmente con tablas derivadas, el uso de GUID puede disminuir significativamente el rendimiento.
si positivamente, absolutamente debe tener una identificación única, entonces GUID. Es decir, si alguna vez vas a fusionar, sincronizar, replicar, probablemente deberías usar un GUID.
Para cosas menos robustas, una int, debería ser suficiente dependiendo de qué tan grande crecerá la tabla.
Como en la mayoría de los casos, la respuesta correcta es, depende.