Tout d'abord, il y a déjà un problème car les données ne sont pas normalisées. Création de n'importe quel sorte d'index sur un tas de colonnes de texte est quelque chose qui devrait être évité autant que possible. Même si ces colonnes ne sont pas du texte (et je suppose qu'elles le sont), cela n'a toujours pas de sens d'avoir l'artiste, l'album et la chanson dans la même table. Une meilleure beaucoup design pour ce serait:
Artists (
ArtistID int NOT NULL IDENTITY(1, 1) PRIMARY KEY CLUSTERED,
ArtistName varchar(100) NOT NULL)
Albums (
AlbumID int NOT NULL IDENTITY(1, 1) PRIMARY KEY CLUSTERED,
ArtistID int NOT NULL,
AlbumName varchar(100) NOT NULL,
CONSTRAINT FK_Albums_Artists FOREIGN KEY (ArtistID)
REFERENCES Artists (ArtistID))
Songs (
SongID int NOT NULL IDENTITY(1, 1) PRIMARY KEY CLUSTERED,
AlbumID int NOT NULL,
SongName varchar(100) NOT NULL,
NumberOfListens int NOT NULL DEFAULT 0
CONSTRAINT FK_Songs_Albums FOREIGN KEY (AlbumID)
REFERENCES Albums (AlbumID))
Une fois que vous avez cette conception, vous avez la possibilité de rechercher des albums individuels et des artistes ainsi que des chansons. Vous pouvez également ajouter des index de couverture pour accélérer les requêtes, et les index seront beaucoup plus petit et donc plus rapide que la conception originale.
Si vous n'avez pas besoin de faire des requêtes de plage (ce que vous n'avez probablement pas), vous pouvez remplacer la clé IDENTITY par une ROWGUID si cela convient mieux à votre conception; ce n'est pas vraiment important dans ce cas, je voudrais coller avec le simple IDENTITY.
Vous devez faire attention avec les clés de clustering. Si vous vous regroupez sur une touche qui n'est absolument pas séquentielle (et que l'artiste, l'album et le nom de la chanson sont définitivement non séquentiels), vous vous retrouvez avec des divisions de pages et d'autres comportements malveillants. Tu ne veux pas ça. Et comme Marc le dit, une copie de cette clé est ajoutée à chaque index, et vous ne voulez certainement pas cela lorsque votre clé est longue de 300 ou 600 octets.
Si vous voulez être en mesure d'interroger rapidement le nombre d'écoutes pour une chanson spécifique de l'artiste, l'album et le nom de la chanson, il est en fait assez simple avec la conception ci-dessus, vous avez juste besoin d'indexer correctement:
CREATE UNIQUE INDEX IX_Artists_Name ON Artists (ArtistName)
CREATE UNIQUE INDEX IX_Albums_Artist_Name ON Albums (ArtistID, AlbumName)
CREATE UNIQUE INDEX IX_Songs_Album_Name ON Songs (AlbumID, SongName)
INCLUDE (NumberOfListens)
maintenant, cette requête sera rapide:
SELECT ArtistName, AlbumName, SongName, NumberOfListens
FROM Artists ar
INNER JOIN Albums al
ON al.ArtistID = ar.ArtistID
INNER JOIN Songs s
ON s.AlbumID = al.AlbumID
WHERE ar.ArtistName = @ArtistName
AND al.AlbumName = @AlbumName
AND s.SongName = @SongName
Si vous consultez le plan d'exécution, vous verrez 3 index cherche - il est aussi rapide que vous pouvez l'obtenir. Nous avons garanti le même caractère unique que dans la conception originale et optimisé pour la vitesse. Plus important encore, il est normalisé, donc un artiste et un album ont chacun leur propre identité, ce qui facilite grandement la gestion à long terme. Il est beaucoup plus facile de rechercher "tous les albums de l'artiste X." beaucoup plus facile et plus rapide de rechercher" toutes les chansons sur l'album Y. "
Lors de la conception d'une base de données, la normalisation devrait être votre premier souci, l'indexation devrait être votre deuxième. Une fois que vous avez un design normalisé, la meilleure stratégie d'indexation devient un peu évidente
+1, bien mis !!! –
Désolé je ne peux pas entrer trop dans les détails sur la base de données sur laquelle je travaille. Il a environ 50 tables et il est trop complexe pour taper plus de détails. Êtes-vous en train de dire que la mise en cluster de clés primaires ou même la mise en cluster de colonnes qui ne sont pas des clés primaires provoquent un vidage dans la mémoire du serveur? En utilisant mon exemple, pratiquement chaque table de cette base de données a une colonne Artiste et Album comme clé primaire, puis 1 à 3 autres colonnes comme clé (s) primaire. C'est mal conçu et je le réorganise. – Sarah
@Sarah: si votre ** clef de cluster ** est assez grande (par exemple un VARCHAR (50) ou pire, deux colonnes ou plus), alors OUI - vous gaspillez de l'espace mémoire disque et serveur - et vous ' Je n'en retire pas vraiment grand-chose. –