SQL: à la clé primaire ou pas à la clé primaire?

Question

J'ai un tableau avec des ensembles de paramètres pour les utilisateurs. Il contient les colonnes suivantes:

UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME

L'ID utilisateur avec Set et Key sont uniques. Un utilisateur spécifique ne peut donc pas avoir deux clés identiques dans un ensemble de paramètres particulier. Les paramètres sont récupérés par jeu. Ainsi, si un utilisateur demande une certaine clé à un certain jeu, l'ensemble est téléchargé. Ainsi, la prochaine fois qu'une clé du même jeu est nécessaire, elle ne doit pas nécessairement aller dans la base de données. .

Devrais-je créer une clé primaire sur les trois colonnes (ID utilisateur, ensemble et clé) ou créer un champ supplémentaire contenant une clé primaire (par exemple, un entier auto-incrémenté appelé SettingID, mauvaise idée, je suppose), ou non créer une clé primaire et créer un index unique?

----- UPDATE -----

Juste pour clarifier les choses: Ceci est une table de fin de ligne, elle n’est pas jointe de toute façon. UserID est un FK à la table des utilisateurs. L'ensemble n'est pas un FK. C'est à peu près une table d'assistance pour mon interface graphique. À titre d’exemple, lorsqu’ils visitent pour la première fois certaines parties du site Web, les utilisateurs obtiennent un ballon d’aide qu’ils peuvent fermer s’ils le souhaitent. Une fois qu'ils auront cliqué dessus, j'ajouterai un paramètre à l'option "GettingStarted". définir qui indiquera qu'ils helpballoon X a été désactivé. La prochaine fois que l'utilisateur accédera à la même page, le paramètre indiquera que la bulle d'aide X ne devrait plus être affichée.

Answer 1

  

Devrais-je créer une clé primaire sur les trois colonnes (ID utilisateur, ensemble et clé)

Faites celui-ci.

L'utilisation de la clé primaire de substitution génère une colonne supplémentaire qui n'est pas utilisée à d'autres fins.

La création d'un UNIQUE INDEX avec une clé primaire de substitution est identique à la création d'un PRIMARY KEY non mis en cluster , et entraîne une recherche supplémentaire KEY ce qui est pire pour la performance.

La création d'un UNIQUE INDEX sans PRIMARY KEY donnera une table HEAP-organisée qui nécessitera une recherche RID supplémentaire pour accéder aux valeurs: pas très bon aussi.

Answer 2

Avoir des clés uniques composites n’est généralement pas une bonne idée.

Le fait de disposer de données pertinentes pour l’entreprise comme clé primaire peut également vous causer des ennuis. Par exemple, si vous devez modifier la valeur. S'il n'est pas possible dans l'application de modifier la valeur, celle-ci pourrait l'être ultérieurement ou doit être modifiée dans un script de mise à niveau.

Il est préférable de créer une clé de substitution, un numéro automatique qui n'a pas de signification commerciale.

Modifier après votre mise à jour:

Dans ce cas, vous pouvez penser à n'avoir aucune clé primaire sur le plan conceptuel et à faire de ces trois colonnes la clé primaire d'une clé unique composite (pour la rendre modifiable).

Answer 3

Combien de clés et de sets avez-vous? Doivent-ils être varchar (50) ou peuvent-ils pointer vers une table de recherche? Si vous pouvez convertir cet ensemble et cette clé en SetId et KeyId, vous pouvez créer votre clé primaire sur les 3 valeurs entières qui seront beaucoup plus rapides.

Answer 4

J'essaierais probablement de m'assurer que l'ID utilisateur était un identifiant unique, plutôt que d'avoir des doublons dans le code. Les clés composites tendent à devenir confuses plus tard dans la vie de votre code.

Je suppose qu'il s'agit d'un champ de recherche pour les valeurs de configuration, vous pouvez donc utiliser la clé composite si c'est le cas. Les données sont déjà là. Vous pouvez garantir son unicité en utilisant la clé primaire. Si vous changez d'avis et décidez plus tard que cela ne vous convient pas, vous pouvez facilement ajouter un SettingId et faire de la clé composite d'origine un index unique.

Answer 5

Créez une clé primaire séparée. Quelles que soient les modifications apportées à la logique des entreprises, quelles nouvelles règles devront être appliquées à votre champ Key VARCHAR (50) - le fait d’avoir une clé primaire vous rend totalement indépendant de la logique des entreprises.

Answer 6

D'après mon expérience, tout dépend du nombre de tables qui utiliseront cette table en tant qu'informations FK. Voulez-vous 3 colonnes supplémentaires dans vos autres tables juste pour reporter un FK?

Personnellement, je créerais une autre colonne FK et mettrais une contrainte unique sur les trois autres colonnes. Cela rend les clés étrangères de cette table beaucoup plus faciles à avaler.

Answer 7

Je ne suis pas un partisan des clés composites, mais dans ce cas, en tant que table de fin de ligne, cela peut avoir un sens. Toutefois, si vous autorisez les valeurs nulles dans l’un de ces trois champs, car une ou plusieurs valeurs ne sont pas connues au moment de l’insertion, il peut y avoir une difficulté et un index unique peut-être meilleur.

Answer 8

Il vaut mieux avoir l'ID utilisateur sous la forme newid () 32 bits ou un identifiant unique, car UserID en tant qu'int donne un indice à l'utilisateur du probable UserID. Cela résoudra également votre problème de clé composite.