SQL Server - Dénormaliser des tables de jointures pour améliorer les performances

Question

Actuellement, j'ai une énorme table utilisateur, quelques millions de lignes je crois, et cette table utilisateur est liée à une table UserType via une table UserTypeJoin. La recherche et le filtrage prennent beaucoup de temps en raison de toutes les jointures à la table UserType. J'ai étudié la possibilité d'utiliser une vue indexée, mais lorsque j'ai essayé de créer l'index cluster, on m'a dit que les index clusterisés ne peuvent pas être appliqués aux vues avec des jointures à gauche. Et tous les utilisateurs n'ont pas de UserType, donc je dois faire une jointure à gauche. Donc maintenant je pense que la dénormalisation est ma meilleure approche.

Ma structure actuelle de la table ressemble à ceci:

USER 
UserId 
UserName 
Sex 
Description 

USER TYPE JOIN 
UserId 
UserTypeId 

USER TYPE 
UserTypeId 
Name 

Et je pense à changer la structure à ceci:

USER 
UserId 
UserName 
IsUserTypeX bit 
IsUserTypeY bit 
IsUserTypeZ bit 
etc... 

Un utilisateur peut avoir entre 0 et 11 UserTypes.

Une requête typique que j'utiliserais avec mes données serait de rechercher des utilisateurs en utilisant leur nom, leur sexe, leur description, ou leurs types d'utilisateurs, ou une combinaison de ces attributs. Ces tableaux sont principalement utilisés pour la recherche et pas vraiment pour l'écriture, et toutes les recherches que j'ai faites dernièrement me disent que les tables intensives en lecture doivent être dénormalisées.

Est-ce ma meilleure option dans cette situation?

Ou existe-t-il un moyen de créer la vue indexée sans utiliser une jointure à gauche mais toujours retourner toutes les lignes? Ce serait certainement l'approche la plus facile car je n'aurais pas à changer de grandes quantités de code.

Answer 1

Une chose que vous souhaitez faire, dans ce cas, est d'ajouter un autre UserType, appelons-le "Untyped". Faites-en le type par défaut lors de l'insertion de nouveaux utilisateurs. Maintenant, vous pouvez utiliser une jointure interne et ne pas perdre de lignes. C'est la gestion de données de klunkier, mais le compromis peut valoir la peine dans votre cas.

Récupérez-vous toutes les lignes et ensuite le filtrage? Il y a beaucoup de situations où il vaut mieux faire le filtrage d'abord, puis la jointure. L'optimiseur de requête utilise généralement cette stratégie si vous placez les critères de filtre dans la même requête que la jointure.