J'ai plusieurs tables de base de données qui contiennent simplement une seule colonne et très peu de lignes, souvent juste un identifiant de quelque chose défini dans un autre système. Ces tables sont ensuite référencées avec des clés étrangères d'autres tables. Par exemple une table contient des codes de pays (SE, DK, US, etc.). Toutes les valeurs sont toujours des clés naturelles uniques et elles sont utilisées comme clés primaires dans d'autres systèmes (hérités).
Il semble vraiment inutile d'introduire une nouvelle clé de substitution à ces tables, ou?
En général, quels sont les cas exceptionnels lorsque les clés de substitution ne doivent pas être utilisées?
6 Réponses :
Les clés naturelles (codes de pays dans votre cas) sont meilleurs parce que
L'inconvénient des touches naturelles est qu'ils sont liés à la logique de l'information, et s'il change (ce qui se passe parfois), vous devez modifier beaucoup de tables, en révision essentiellement une partie importante de la DB.
Donc, si dans votre DB, la logique ne change pas pendant de nombreuses années, utilisez des clés naturelles.
Les touches de substitution ne doivent jamais être présentées à l'utilisateur, elles sont utilisées pour associer des données. Je présenterais normalement des clés primaires à l'utilisateur (sauf si elles sont des clés naturelles dans ce cas, elles sont présentées comme des «clés» mais plutôt comme les données elles-mêmes).
J'ai ajouté à ma réponse que c'est un avantage pour le développement. Souvent, vous avez une vidage de texte d'une table ou travaillez dans un autre environnement non idééide et vous ne pouvez pas consulter la table de référence. Les clés de substitution dans ce cas ralentissent considérablement le travail de manière significative.
C'est vrai, à moins que le substitut ne fait partie de l'enregistrement (et de manière appropriée), les frais généraux pour la table de liaison ou quelle autre méthode est utilisée peut devenir significative à mesure que la demande de données augmente.
En regardant mon premier commentaire, j'ai réussi à compléter le désordre en anglais. Il devrait être "Je ne présenterais pas normalement des clés primaires" et "présenté non comme" clés "". Parfois, ma capacité à vous embrouiller une phrase m'achemine.
Je ne suis pas sûr qu'il y ait un cas d'exception lorsque les clés de substitution ne doivent pas être utilisées. Je pense que la nature d'une clé de substitution, de manière générale de faire une référence globalement unique, est particulièrement pertinente lorsqu'il est appliqué à un système tel que vous décrivez.
Bien que chacune des touches primaires satellite que vous mentionnez peut être unique dans sa propre portée, vous ne pouvez pas vraiment garantir qu'ils resteront uniques dans l'ensemble de votre environnement interconnecté, surtout s'il s'agrandit. Je soupçonne que les concepteurs d'origine essaient de la preuve futurs leur système ou de conduire la dernière mode qu'ils avaient appris;)
Une clé naturelle est également globalement unique, sinon ce ne serait pas une clé naturelle. Si vous voulez dire que les touches de substitution sont uniques dans toute la base de données, vous dites que vous utilisez un seul compteur partagé sur toutes les tables ?!
S'il était vrai que les clés naturelles étaient globalement uniques, alors il n'y aurait pas besoin de clés de substitution du tout. Les clés naturelles ont tendance à être uniques dans le cadre de laquelle ils ont été sélectionnés mais souvent pas au-delà. Lorsque vous travaillez dans un environnement comme une entreprise où il peut y avoir de nombreux systèmes similaires créés au fil du temps (et acquis grâce à l'achat de la société) par des éléments variables de la société, vous constatez souvent que des clés naturelles ne sont pas uniques ou, tout aussi mauvais, il y a plusieurs clés pour une seule cible.
Je devrais ajouter que je pense beaucoup à une manière de l'entrepôt de données. Pour échanger des données entre les systèmes, j'avais tendance à utiliser une passerelle au milieu et à prendre le succès de la performance pour permettre une extensibilité à l'avenir.
Je dirais que les critères suivants doivent être remplis:
Votre clé naturelle Votre clé naturelle devrait être aussi petite que l'INT, par ex. Pas significativement plus de 4 octets de taille (n'utilisez pas de Varchar (50) pour votre PK, et surtout pas pour votre clé de clustering dans SQL Server!)
Votre clé naturelle devrait être stable, par exemple. Ne changez jamais (ok, avec des codes de pays ISO, cela est presque donné - sauf lorsque des pays comme la Yougoslavie ou l'ESSR s'effondrent, ou tout comme les deux germanies unissent - mais c'est assez rare)
Si ces conditions sont remplies, vous pouvez envisager une clé naturelle comme votre PK - mais qui devrait être l'exception de 2% dans toutes vos tables - pas la norme.
L'effondrement et l'unification des pays ne sont pas de bons exemples d'un changement clé en soi; Lorsqu'une entité se divise en plusieurs ou plusieurs entités se faire fusiller - cela va être tout à fait un problème, quelle que soit la manière dont ces entités sont identifiées. Néanmoins, +1 pour très bon (lecture: très strict :) critères pour les clés naturelles. Personnellement, je pense que 2% est une surestimation, cependant. :)
Il y a un débat de longue date à ce sujet. Si vous avez Google pour "Keys naturelles de substitution de substitution", vous obtiendrez de nombreux liens. Je soupçonne donc que vous obtiendrez un débat plutôt qu'une réponse claire ici.
de Cet article :
Modelers de données (pour cette discussion, je comprends toute personne qui a conçu des tables pour une base de données) sont divisées sur cette question: certains modélisateurs jurent par la clé de substitution; D'autres mourraient avant d'avoir utilisé autre chose qu'une clé naturelle. Une recherche de la littérature sur la modélisation des données et la conception de la base de données ne prend en charge aucun côté, sauf dans l'arène de données de données, dans lequel une clé de substitution est le seul choix pour la dimension et les tableaux de faits.
"... d'autres mourraient avant d'avoir utilisé quelque chose qu'une clé naturelle ..." bien dit. Peut-être que beaucoup d'entre eux sont déjà morts ou démissionnaires. :) Cela expliquerait la prévalence apparente du camp de clé de substitution.
En plus de ce que Marc_s a dit, vous n'avez pas besoin d'une clé surgogate généralement dans une table de liaison qui contient une table contenant deux clés principales différentes uniquement utilisées pour créer de nombreuses relations. En général, une clé composite sur les deux domaines fonctionne correctement ici. C'est l'une des rares fois que je suggère une clé composite, en général, je préfère une clé de substitution et un index unique sur la clé composite.
Utilisation des clés naturelles à des fins d'identification est une bonne idée à chaque fois que les clés naturelles peuvent vraiment faire confiance. Voir la réponse marc_s pour certains cas où les clés naturelles ne peuvent pas faire confiance. Ne vous inquiétez pas trop sur l'efficacité. Même quelque chose de long comme le VIN (numéro d'identification du véhicule) ne traînera pas votre base de données vers le bas beaucoup. Si vous pensez qu'il va, faire quelques tests, se rendant compte que l'efficacité n'échelle pas de façon linéaire.
La principale raison de déclarer une clé primaire est d'empêcher une table de glisser hors de la première forme normale, et ce qui ne représente une relation. L'utilisation d'une clé de substitution peut entraîner auto- incrémentée deux lignes avec différents champs d'identification, mais sinon identiques. Cela vous apportera quelques-uns des problèmes qui vont avec des données qui ne figure pas dans la première forme normale. Et les utilisateurs ne seront pas en mesure d'aider, parce qu'ils ne peuvent pas voir le champ id.
Si peuvent être déterminées par une combinaison de deux ou plusieurs clés étrangères les lignes d'une table, ce que vous avez est une table de relation, parfois appelée une table de liaison ou une table de jonction. Vous êtes habituellement mieux de déclarer une clé primaire composite constitué de toutes les clés étrangères nécessaires.
Si les choix ci-dessus donnent lieu à preformance lent, parfois peut être résolu en créant des indices supplémentaires. Cela dépend de ce que vous faites avec les données.