Index par rapport à clé unique dans SQL Server 2008

Question

J'ai le tableau suivant qui sert à se joindre à 3 tables:

ClientID int 
BlogID int 
MentionID int 

En supposant que les requêtes seront toujours venir par ClientID, je peux créer 1 index à plusieurs colonnes (ClientID , BlogID, MentionID).

La question est, devrais-je le créer comme un index clusterisé ou une clé unique? Je comprends qu'un index clusterisé stocke les données sur ses nœuds feuilles. Bien sûr, dans ce cas, l'index est les données, donc je ne sais pas si SQL Server va dupliquer les données ou non. Quoi qu'il en soit, je ne trouve rien sur MSDN sur la signification de l'utilisation de "clé unique".

En quoi cela diffère-t-il de Type = Index & IsUnique = yes? Est-ce que quelqu'un peut me dire les avantages dans chaque sens?

Answer 1

Il semble que vous demandez la différence entre:

MYTABLE 
id integer primary key autoincrement 
clientid integer 
blogid integer 
mentionid integer 
-- with a unique composite index on (clientid, blogid, mentionid) and three foreign key constraints 

et

MYTABLE 
clientid 
blogid 
mentionid 
-- with a composite primary key on (clientid, blogid, mentionid) and three foreign key constraints 

et

MYTABLE 
id integer primary key autoincrement 
    clientid integer 
    blogid integer 
    mentionid integer 
    with an index on clientid and also an index on blogid and the three foreign key constraints 

Dans la première, vous avez l'index sur l'entier clé primaire et aussi l'index unique alternatif sur la triade. Si la seconde, vous avez seulement l'index unique sur la clé primaire triadique. Dans la troisième, vous avez un index unique sur la clé primaire entière et deux autres index non uniques, l'un sur clientid et l'autre sur blogid. Le gain de performance avec l'efficacité légèrement supérieure de la deuxième option serait de minimis, et donc je fonderais la décision sur d'autres facteurs. Le troisième est le plus flexible en termes de requêtes et offre une plus grande simplicité de codage; il offre l'avantage des index sur le client et le blog, dans le cas où vous vouliez avoir une requête avec blog, pas client, dans la clause WHERE. En ce qui concerne le codage, certains outils graphiques et middleware ont des problèmes avec les clés primaires en plusieurs parties, et votre logique de mise à jour/insertion/suppression sera plus simple si elle doit traiter une seule colonne PK entière. J'ai trouvé que la simplicité du code et la facilité de maintenance sont bien meilleures que quelques secondes ou seulement quelques fractions de secondes d'amélioration du temps de réponse aux requêtes.

Answer 2

• A unique index, un unique key et un unique constraint sont essentiellement la même chose. Ils résultent en un index qui renforce l'unicité. En cluster, signifie que l'index devient la table elle-même. Il est bon d'avoir un index cluster, sinon la table se trouve dans un tas non ordonné .

Unique et en cluster sont des propriétés non apparentées. Vous pouvez les combiner comme vous le souhaitez. Donc dans votre cas, je créerais un index clusterisé unique. La manière normale de le faire consiste à créer l'index en tant que clustered primary key.

Answer 3

Les données seront dupliquées si vous créez un index unique en cluster sur vos trois colonnes.

L'index cluster unique sera être les données - et l'indice en même temps :-)

Comme il s'agit d'une table de jointure à trois voies, cet index ordonné en clusters n'a probablement beaucoup de sens. Je dirais: allez-y!

Answer 4

L'index clusterisé est "la table elle-même", c'est-à-dire que les nœuds d'index sont organisés dans une arborescence et que ses nœuds feuilles contiennent des données de ligne. L'index cluster ne doit pas être déclaré comme unique (bien que ce soit généralement le cas); s'il n'est pas unique, le serveur ajoute implicitement un "uniqalizer" à cet index, de sorte que chaque ligne est identifiée de façon unique.

D'autres index stockent la valeur d'index clusterisée sous forme de nœuds feuilles (et éventuellement d'autres colonnes si elles sont incluses avec la clause INCLUDE dans la structure CREATE INDEX).

Tout index peut être décimal comme unique, de sorte que le serveur effectue une vérification supplémentaire pour éviter l'entrée de valeurs dupliquées dans la table.

Answer 5

UNIQUE INDEX et UNIQUE CONSTRAINT sont des concepts quelque peu différents.

• UNIQUE CONSTRAINT est un concept logique et signifie « assurez-vous que cette colonne est unique, peu importe comment »
• UNIQUE INDEX est un concept physique et signifie « créer un index B-Tree sur cette colonne et ne parviennent pas à chaque fois que les doublons y sont insérés "

Cette dernière implique la première mais pas l'inverse.

Par exemple, dans Oracle, si vous avez un index non unique sur col1:

• CREATE UNIQUE INDEX (col1) échouera et dire « ces colonnes sont déjà indexées »
• ALTER TABLE ADD CONSTRAINT UNIQUE(col1) réussira et utiliser l'index existant pour contrôler la contrainte.

Utilisez CONSTRAINT si vous voulez juste la colonne d'être unique et INDEX si vous connaissez un index B-Tree est ce que vous voulez (pour accélérer les recherches, etc.).