tablas primary nonclustered non indice indexar estructura ejemplos ejemplo diseño crear clustered cluster sql-server sql-server-2005 tsql indexing clustered-index

sql-server - primary - indices clustered y nonclustered sql server



Razones para no tener un índice agrupado en SQL Server 2005 (5)

En cualquier tabla de datos o búsqueda "normal": no, no veo ningún motivo en absoluto.

En cosas como tablas de importación masiva, o tablas temporales, depende.

Sorprendentemente, para algunas personas, parece que tener un buen índice agrupado realmente puede acelerar operaciones como INSERT o UPDATE. Ver Kimberly Tripps excelente El debate sobre el índice agrupado continúa ... publicación de blog en la que explica en gran detalle por qué este es el caso.

En este sentido, no veo ninguna razón válida para no tener un buen índice agrupado (estrecho, estable, único, cada vez mayor = INT IDENTITY como la opción más obvia) en cualquier tabla de SQL Server.

Para conocer en profundidad cómo y por qué elegir las claves de agrupamiento, lea todas las excelentes publicaciones de blog de Kimberly Tripp sobre el tema:

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustered-Index.aspx

¡Excelentes cosas de la "Reina de la indexación"! :-)

Heredé algunos scripts de creación de bases de datos para una base de datos SQL SERVER 2005.

Una cosa que he notado es que todas las claves primarias se crean como índices NON CLUSTERED en lugar de agruparse.

Sé que solo puede tener un índice agrupado por tabla y que puede querer tenerlo en una columna de clave no primaria para el rendimiento de búsqueda de búsquedas, etc. Sin embargo, no hay otros índices CLUSTERED en las tablas en las preguntas.

Entonces mi pregunta es si hay razones técnicas para no tener índices agrupados en una columna de clave principal aparte de los anteriores.

Cuadros agrupados frente a tablas del montón

(Buen artículo sobre el tema en www.mssqltips.com )

Tabla HEAP (sin índice agrupado)

  • Los datos no se almacenan en ningún orden en particular

  • Los datos específicos no se pueden recuperar rápidamente, a menos que también haya índices no agrupados

  • Las páginas de datos no están vinculadas, por lo que el acceso secuencial debe referirse a las páginas del mapa de asignación de índices (IAM)

  • Como no hay un índice agrupado, no se necesita tiempo adicional para mantener el índice

  • Como no hay un índice agrupado, no existe la necesidad de espacio adicional para almacenar el árbol de índice agrupado

  • Estas tablas tienen un valor index_id de 0 en la vista del catálogo sys.indexes

Tabla agrupada

  • Los datos se almacenan en orden en función de la clave del índice agrupado

  • Los datos se pueden recuperar rápidamente en función de la clave del índice agrupado, si la consulta utiliza las columnas indexadas

  • Las páginas de datos están vinculadas para un acceso secuencial más rápido. Se necesita tiempo adicional para mantener el índice agrupado basado en INSERTS, UPDATES y DELETES.

  • Se necesita espacio adicional para almacenar el árbol de índice agrupado Estas tablas tienen un valor index_id de 1 en la vista del catálogo sys.indexes

Lea mi respuesta en " No hay acceso directo a la fila de datos en la tabla agrupada, ¿por qué?" , primero. Específicamente ítem [2] Advertencia.

Las personas que crearon la "base de datos" son cretinos. Tuvieron:

  • un grupo de spreadset no normalizados, no tablas relacionales normalizadas
  • los PK son todas columnas de IDENTIDAD (las hojas de cálculo están vinculadas entre sí, deben navegarse una por una por una); no hay acceso relacional o poder relacional en la base de datos
  • tenían PRIMARY KEY, que producen CLUSTERED ÚNICO
  • encontraron que eso impedía la concurrencia
  • eliminaron el IC y los convirtieron en todos los NCI
  • eran demasiado perezosos para terminar la inversión; nominar a un suplente (NCI actual) para convertirse en el nuevo CI, para cada mesa
  • la columna IDENTIDAD sigue siendo la clave principal (no es realmente, pero está en esta implementación hamfisted)

Para tales colecciones de hojas de cálculo enmascaradas como bases de datos, cada vez es más común evitar las EC por completo, y solo tienen NCI más el Heap. Obviamente no obtienen el poder o los beneficios de la IC, pero diablos, no obtienen el poder o beneficio de las bases de datos relacionales, entonces ¿a quién le importa que no obtengan el poder de los CI (que fueron diseñados para bases de datos relacionales, que son suyas? no es). Por la forma en que lo ven, tienen que "refactorizar" la maldita cosa de vez en cuando de todos modos, entonces, ¿para qué molestarse? Las bases de datos relacionales no necesitan "refactorización".

Si necesita analizar más esta respuesta, publique CREATE TABLE / INDEX DDL; de lo contrario, es un argumento académico que pierde el tiempo.

Con algunos servidores de b-tree / lenguajes de programación aún utilizados en la actualidad, los archivos de ascii planos de longitud fija o variable se utilizan para almacenar datos. Cuando se agrega un nuevo registro / fila de datos a un archivo (tabla), el registro se (1) se agrega al final del archivo (o reemplaza un registro eliminado) y (2) los índices se equilibran. Cuando los datos se almacenan de esta manera, no tiene que preocuparse por el rendimiento del sistema (en lo que respecta al funcionamiento del servidor b-tree para devolver un puntero al primer registro de datos). El tiempo de respuesta solo se ve afectado por el número de nodos en sus archivos de índice.

Cuando entres en el uso de SQL, con suerte te darás cuenta de que el rendimiento del sistema debe tenerse en cuenta cada vez que escribes una instrucción SQL. Usar una instrucción "ORDER BY" en una columna no indexada puede poner a un sistema de rodillas. Usar un índice agrupado podría poner una carga innecesaria en la CPU. Es el siglo 21 y me gustaría no tener que pensar en el rendimiento del sistema cuando se programa en SQL, pero aún lo hacemos.

Con algunos lenguajes de programación más antiguos, era obligatorio usar un índice cada vez que se recuperan datos ordenados. Solo desearía que este requisito todavía estuviera vigente hoy. Solo me puedo preguntar cuántas empresas han actualizado sus sistemas informáticos lentos debido a una declaración SQL mal escrita sobre datos no indexados.

En mis 25 años de programación, nunca he necesitado que mis datos físicos estén almacenados en un orden particular, así que tal vez es por eso que algunos programadores evitan el uso de índices agrupados. Es difícil saber cuál es la compensación (tiempo de almacenamiento, tiempo de recuperación de versículos), especialmente si el sistema que está diseñando puede almacenar millones de registros algún día.