Serveur SQL:identifiant unique plus composé entier PK… quel type d'index utiliser ?

Question

J'ai une table de jonction dans ma base de données SQL Server 2005 composée de deux colonnes :

• object_id (identifiant unique)

• property_id (entier)

Ces valeurs forment ensemble une clé primaire composée.

Quelle est la meilleure façon de créer cet indice PK pour les performances SELECT ?

Si les colonnes étaient deux entiers, j'utiliserais simplement un index clusterisé composé (valeur par défaut).Cependant, j'ai entendu de mauvaises choses à propos des index clusterisés lorsque des identifiants uniques sont impliqués.

Quelqu'un a-t-il vécu cette situation ?

Answer 1

Oui, les GUID sont vraiment mauvais pour les index clusterisés, car les GUID sont par conception très aléatoires et conduisent ainsi à une fragmentation massive et donc à des problèmes de performances.

Voir le blog de Kim Tripp - notamment "Le débat sur les index clusterisés se poursuit" et "GUID comme clé PRIMAIRE et/ou CLUSTERED" - pour de nombreuses informations générales précieuses.

Si vous avez vraiment besoin d'un index sur ces DEUX colonnes, je suggérerais un index non clusterisé - il peut s'agir d'un index primaire - mais mieux vaut ne pas être un index clusterisé.

Marc

Answer 2

Une alternative consiste à utiliser ce que l'on appelle une clé de substitution (qui peut d'ailleurs également être attribuée comme clé primaire).

Par exemple, ajouter une colonne d'identité qui peut être utilisée pour identifier de manière unique chaque ligne du tableau, c'est-à-direune clé primaire.

Comprenez qu'un GUID est utilisé pour identifier un enregistrement globalement dans SQL Server (ce qui n'est sans doute pas une pratique relationnellement correcte, mais cela ne nous concerne pas ici).

La colonne d'identité, désormais également une clé primaire, peut/aura un index clusterisé appliqué.Un index distinct et non clusterisé peut ensuite être appliqué à la clé composée décrite par l'affiche originale.

Cette pratique évite le problème des divisions de pages fréquentes au sein de l'index clusterisé (insertions dans une clé primaire GUID aléatoire) et produit un index clusterisé plus petit et plus efficace, tout en préservant les relations définies dans la base de données.

Définition de la clé de substitution : http://en.wikipedia.org/wiki/Surrogate_key

Answer 3

Je créerais une colonne d'identité, puis en ferais votre clé primaire et votre index clusterisé.Vous pouvez ensuite créer des index non clusterisés sur l'ID de propriété objectid selon vos besoins.

Vous pouvez créer une contrainte unique pour garantir l'unicité de votre clé.

La raison en est que les lignes seront insérées séquentiellement, ce qui réduira les divisions de page.de plus, l'utilisation d'un entier pour votre PK signifie que vous avez une valeur plus petite pour votre index clusterisé.