Y a-t-il un avantage à une clé primaire qui comprend toutes les colonnes de la table?

J'ai un tableau avec quatre colonnes qui ne sont pas toutes nullables, et les données sont telles que les quatre sont nécessaires pour distinguer un enregistrement unique. Cela signifie que si je devais créer une clé primaire, elle devrait comprendre toutes les colonnes. Les requêtes sur la table consisteront presque toujours à retirer un seul enregistrement, c'est-à-dire que toutes les colonnes seront filtrées dans la requête.

Étant donné que chaque colonne devra être recherchée, le fait d'avoir une clé primaire me profite-t-il du tout (en plus d'imposer l'unicité des enregistrements)?

Dans votre cas, ces champs sont naturels clé .

Clé de substitution:

Les clés de substitution sont des clés qui n'ont aucune signification «commerciale» et sont uniquement utilisées pour identifier un enregistrement dans le tableau. Ces clés sont générées par une base de données (exemple: identité dans SQL Server, séquence dans Oracle, séquence / identité dans DB2 UDB, etc.) ou générées par le système (comme celles générées via une table dans le schéma).

Clé naturelle:

Les clés sont naturelles si l'attribut qu'il représente est utilisé pour l'identification indépendamment du schéma de base de données. Cela signifie essentiellement que les clés sont naturelles si les gens les utilisent par exemple: numéros de facture, numéros d'identification fiscale, SSN, etc.

Clés de substitution vs clés naturelles pour la clé primaire

Je préfère ajouter une clé de substitution pour séparer la gestion des modèles d'entreprise et de base de données. Une autre question consiste à utiliser un index cluster et non cluster sur la clé primaire. Si vous modifiez la table (table non statique, elle comporte des insertions ou des mises à jour intensives), vous obtiendrez un problème de performances en cas d'utilisation d'un index cluster sur une clé augmentée non monotone.

Il est généralement recommandé que vous ayez une clé de substitution dans de telles situations, donc des clés étrangères dans d'autres tables (et toutes les références d'enregistrement qui peuvent être stockées en externe, comme si elles sont portées sur des chaînes de requête où une demande http (s) fait référence à une des enregistrements) ont quelque chose à se référer qui ne changera pas si les données de la ligne changent. Si vous faites cela, ce serait votre clé primaire.

Si vous n'ajoutez pas une telle clé de substitution, la manière dont vous décrivez les données d'accès ayant les quatre colonnes comme clé primaire ne serait pas un inconvénient. Si vous faites de la clé l'index cluster de la table, cela aidera ces requêtes car il y aura un niveau dans l'arborescence b sur le disque pour descendre pour trouver les données pour une ligne donnée.

Les clés composites en tant que clés primaires rencontrent également des problèmes de taille d'index qui peuvent affecter l'utilisation du disque, les vitesses io et les sauvegardes. Vous voudrez peut-être consulter les articles de Kimberly Tripp sur les clés primaires et les index clusterisés ici: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

Je suggérerais moi aussi une clé de substitution dans ce cas au lieu d'une clé naturelle.

Si vous avez un tableau représentant une relation plusieurs-à-plusieurs qui ne comporte que 2 colonnes, cela semble raisonnable.

Cf. cette question SO

Mais j'avoue, que j'ajoute des clés de substitution même dans ces cas.