2009-02-24 23 views

Respuesta

25

No, no se puede agrupar. Sin embargo, si no lo define explícitamente como no agrupado y no hay un índice agrupado en la tabla, se creará como agrupado.

10

También se podría agregar que con frecuencia es MALO permitir que la clave primaria se agrupe. En particular, cuando la clave primaria es asignada por una IDENTIDAD, no tiene un significado intrínseco, por lo que cualquier esfuerzo para mantener la tabla ordenada en consecuencia se desperdiciará.

Considere la posibilidad de una tabla Producto, con ProductID INT IDENTITY PRIMARY KEY. Si esto está agrupado, entonces los productos que están relacionados de alguna manera es probable que se extiendan por todo el disco. Podría ser mejor agrupar por algo en lo que probablemente hagamos consultas, como el ID de fabricante o el ID de categoría. En cualquiera de estos casos, un índice agrupado (en igualdad de condiciones) hará que la consulta correspondiente sea mucho más eficiente.

Por otro lado, la clave externa en una tabla secundaria que apunta a esto podría ser un buen candidato para la agrupación (mi objeción es para la columna que realmente tiene el atributo IDENTIDAD, no sus parientes). Por lo tanto, en mi ejemplo anterior, es probable que ManufacturerID sea una clave foránea para una tabla Manufacturer, donde se configura como IDENTITY. Esa columna no se debe agrupar, pero la columna del Producto que hace referencia a ella podría hacerlo en buena medida.

+1

La presencia de identidad en la mayoría de los casos significa que habrá acceso a los registros por su identidad, por lo que la clave principal agrupada en el campo de identidad parece ser una buena idea. –

+2

@ C-F: esa no es una razón para agruparse. Si realiza una consulta basada en esa clave principal, el índice lo llevará allí. Y, posiblemente, también más rápido, ya que es casi seguro que requerirá menos IO para pasar por un índice relativamente estrecho en comparación con el ancho total de las filas en el índice agrupado. –

Cuestiones relacionadas