Estoy 100% de acuerdo con usted:usar una INT IDENTITY es mucho mejor!
Los GUID pueden parecer una opción natural para su clave principal, y si realmente debe hacerlo, probablemente podría argumentar para usarlo para la CLAVE PRINCIPAL de la tabla. Lo que recomiendo encarecidamente no hacer es usar la columna GUID como la clave de agrupación , que SQL Server hace de forma predeterminada, a menos que le indique específicamente que no lo haga.
Realmente necesita mantener dos cuestiones separadas:
1) la clave principal es una construcción lógica, una de las claves candidatas que identifica de forma única y fiable cada fila de la tabla. Esto puede ser cualquier cosa, realmente:un INT, un GUID, una cadena:elija lo que tenga más sentido para su escenario.
2) la clave de agrupación (la columna o columnas que definen el "índice agrupado" en la tabla):este es un físico cosa relacionada con el almacenamiento, y aquí, un tipo de datos pequeño, estable y en constante aumento es su mejor elección:INT o BIGINT como su opción predeterminada.
De forma predeterminada, la clave principal en una tabla de SQL Server también se usa como clave de agrupación, ¡pero no tiene por qué ser así! Personalmente, he visto ganancias de rendimiento masivas al dividir la clave principal / agrupada basada en GUID anterior en dos claves separadas:la clave principal (lógica) en el GUID y la clave de agrupación (ordenación) en una IDENTIDAD INT separada (1, 1) columna.
Como Kimberly Tripp - la reina de la indexación - y otros han dicho muchas veces - un GUID como clave de agrupación no es óptimo, ya que debido a su aleatoriedad, conducirá a una fragmentación masiva de páginas e índices y, en general, a un mal rendimiento.
Sí, lo sé, hay newsequentialid() en SQL Server 2005 y versiones posteriores, pero incluso eso no es verdadera y completamente secuencial y, por lo tanto, también sufre los mismos problemas que el GUID, solo que un poco menos prominente.
Luego, hay otro problema a considerar:la clave de agrupamiento en una tabla también se agregará a todas y cada una de las entradas en todos y cada uno de los índices no agrupados en su tabla; por lo tanto, realmente desea asegurarse de que sea lo más pequeño posible. Por lo general, un INT con más de 2 mil millones de filas debería ser suficiente para la gran mayoría de las tablas y, en comparación con un GUID como clave de agrupación, puede ahorrar cientos de megabytes de almacenamiento en el disco y en la memoria del servidor.
Cálculo rápido:uso de INT frente a GUID como clave primaria y de agrupación:
- Tabla base con 1 000 000 de filas (3,8 MB frente a 15,26 MB)
- 6 índices no agrupados (22,89 MB frente a 91,55 MB)
TOTAL:25 MB frente a 106 MB - ¡y eso es solo en una sola mesa!
Un poco más de material para el pensamiento, excelente material de Kimberly Tripp, ¡léalo, léalo de nuevo, digiéralo! Es el evangelio de indexación de SQL Server, realmente.
- GUID como PRIMARY KEY y/o clave agrupada
- El debate sobre el índice agrupado continúa
- Clave de agrupación cada vez mayor:el debate sobre el índice agrupado..........¡otra vez!
- El espacio en disco es barato, eso es no el punto!
