Sql Server: uniqueidentifier plus composé entier PK ... quel type d'index utiliser?

Question

J'ai une base de données table de jonction dans mon SQL Server 2005 qui se composent de deux colonnes:

• object_id (uniqueidentifier) ​​

• property_id (entier)

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

Quelle est la meilleure façon de créer cet index 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 sur les index clusterisés lorsque des identifiants uniques sont impliqués.

Quelqu'un a de l'expérience avec cette situation?

Answer 1

Oui, les GUID sont vraiment mauvais pour les index clusterisés, puisque les GUID sont par nature très aléatoires et entraînent donc une fragmentation massive et donc des problèmes de performances.

Voir le blog de Kim Tripp - notamment "The CLustered Index Debate continues" et "GUIDs as PRIMARY and/or CLUSTERED key" - pour beaucoup d'informations de fond précieux.

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 - il vaut mieux pas un index clusterisé.

Marc

Answer 2

I je voudrais créer une colonne d'identité & puis faire votre clé primaire index cluster &. Vous pouvez ensuite créer des index non clusterisés sur objectid objectid selon vos besoins.

Vous pouvez créer une contrainte unique pour garantir l'unicité de votre clé. La raison de ceci est que les lignes seront insérées séquentiellement, de sorte que votre page de réduction se scinde. En outre, l'utilisation d'un nombre entier pour votre PK signifie que vous avez une valeur plus petite pour votre index clusterisé.

Answer 3

Une alternative consiste à utiliser ce que l'on appelle une clé de substitution (qui peut également être affectée comme clé primaire). Par exemple, ajouter une colonne d'identité qui peut être utilisée pour identifier de façon unique chaque rangée dans la table, c'est-à-dire une clé primaire. Comprendre qu'un GUID est utilisé pour identifier un enregistrement globalement dans SQL Server (ce qui n'est sans doute pas une pratique correcte sur le plan relationnel mais qui ne nous concerne pas ici).

La colonne d'identité, maintenant aussi une clé primaire, peut/va avoir un index clusterisé appliqué. Un index séparé non cluster peut alors être appliqué à la clé composée décrite par l'affiche originale. Cette pratique évite le problème des fractionnements de pages fréquents dans l'index clusterisé (insertion dans une clé primaire GUID aléatoire) ainsi que la production d'un index cluster plus petit et plus efficace, tout en préservant les relations définies dans la base de données.

Surrogate Définition clé: http://en.wikipedia.org/wiki/Surrogate_key