GUID puede parecer una opción natural para su clave principal, y si realmente debe hacerlo, probablemente podría argumentar para usarla para la CLAVE PRINCIPAL de la tabla. Lo que recomiendo encarecidamente no hacer es usar el GUID columna 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:
-
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, unGUID, una cadena:elija lo que tenga más sentido para su escenario. -
la clave de agrupación (la columna o columnas que definen el "índice agrupado" en la tabla):este es un físico algo relacionado con el almacenamiento, y aquí, un tipo de datos pequeño, estable y en constante aumento es su mejor elección:
INToBIGINTcomo 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 agrupamiento (ordenamiento) en un INT IDENTITY(1,1) separado columna.
Como Kimberly Tripp
- la Reina de la indexación - y otros lo han dicho muchas veces - un GUID ya que la clave de agrupación no es óptima, ya que debido a su aleatoriedad, dará lugar 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 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. Normalmente, 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 ahorrarse cientos de megabytes de almacenamiento en el disco y en la memoria del servidor.
Cálculo rápido - usando INT frente a GUID como clave principal 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!
A menos que tenga una muy buena razón , argumentaría usar una INT IDENTITY para casi todas las tablas de datos "reales" como valor predeterminado para su clave principal:es única, es estable (nunca cambia), es estrecha, siempre aumenta:todas las buenas propiedades que desea tener en una clave de agrupación para un rendimiento rápido y confiable de sus tablas de SQL Server.
Si tiene algún valor de clave "natural" que también tiene todas esas propiedades, también puede usarlo en lugar de una clave sustituta. Pero dos cadenas de longitud variable de máx. En mi opinión, 20 caracteres cada uno no cumplen esos requisitos.
