Nous y revoilà, le vieil argument se pose encore ...

Aurions-nous mieux une clé métier comme clé primaire, ou aurions-nous plutôt un identifiant de substitution (c'est-à-dire une identité SQL Server) avec une contrainte unique sur le champ de clé métier?

Veuillez fournir des exemples ou des preuves pour étayer votre théorie.

Tous les deux. Prenez votre gâteau et mangez-le.

Souvenez-vous qu'il n'y a rien de spécial à propos d'une clé primaire, sauf qu'elle est étiquetée comme telle. Ce n'est rien de plus qu'une contrainte NOT NULL UNIQUE, et une table peut en avoir plusieurs.

Si vous utilisez une clé de substitution, vous souhaitez toujours une clé métier pour garantir l'unicité selon les règles métier.

Quelques raisons d'utiliser des clés de substitution:

1. Stabilité : la modification d'une clé en raison d'un besoin professionnel ou naturel aura un impact négatif sur les tables associées. Les clés de substitution doivent rarement, voire jamais, être modifiées car il n'y a pas de signification liée à la valeur.

2. Convention : vous permet d'avoir une convention de dénomination de colonne de clé primaire standardisée plutôt que d'avoir à réfléchir à la façon de joindre des tables avec différents noms pour leurs PK.

3. Vitesse : selon la valeur et le type PK, une clé de substitution d'un entier peut être plus petite, plus rapide à indexer et à rechercher.

Il semble que personne n'ait encore rien dit en faveur des clés non substitutives (j'hésite à dire «naturelles»). Alors voilà ...

Un inconvénient des clés de substitution est qu'elles n'ont aucun sens (citées comme un avantage par certains, mais ...). Cela vous oblige parfois à joindre beaucoup plus de tables dans votre requête que ce qui devrait vraiment être nécessaire. Comparer:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

contre:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

À moins que quelqu'un ne pense sérieusement que ce qui suit est une bonne idée?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Mais" quelqu'un dira, "que se passe-t-il lorsque le code pour MYPROJECT ou VALID ou HR change?" A quoi ma réponse serait: "pourquoi auriez-vous besoin de le changer?" Ce ne sont pas des clés «naturelles» dans le sens où un organisme extérieur va légiférer que dorénavant «VALIDE» devrait être recodé comme «BON». Seul un petit pourcentage de clés «naturelles» entrent vraiment dans cette catégorie - le SSN et le code postal étant les exemples habituels. J'utiliserais certainement une clé numérique dénuée de sens pour des tables comme Personne, Adresse - mais pas pour tout , ce que , pour une raison quelconque, la plupart des gens ici semblent prôner.

Voir aussi: ma réponse à une autre question

La clé de substitution n'aura JAMAIS de raison de changer. Je ne peux pas en dire autant des clés naturelles. Noms de famille, e-mails, numéros ISBN - ils peuvent tous changer un jour.

Les clés de substitution (généralement des entiers) ont la valeur ajoutée de rendre vos relations de table plus rapides, et plus économiques en termes de stockage et de vitesse de mise à jour (encore mieux, les clés étrangères n'ont pas besoin d'être mises à jour lors de l'utilisation de clés de substitution, contrairement aux champs de clé métier, qui changent de temps en temps).

La clé primaire d'une table doit être utilisée pour identifier de manière unique la ligne, principalement à des fins de jointure. Pensez à une table de personnes: les noms peuvent changer et ils ne sont pas garantis uniques.

Pensez aux entreprises: vous êtes une entreprise Merkin heureuse qui fait affaire avec d'autres entreprises à Merkia. Vous êtes assez intelligent pour ne pas utiliser le nom de l'entreprise comme clé primaire, vous utilisez donc l'ID d'entreprise unique du gouvernement de Merkia dans son intégralité de 10 caractères alphanumériques. Merkia modifie ensuite les identifiants de l'entreprise car ils pensaient que ce serait une bonne idée. C'est bon, vous utilisez la fonctionnalité de mises à jour en cascade de votre moteur de base de données, pour un changement qui ne devrait pas vous impliquer en premier lieu. Plus tard, votre entreprise se développe et maintenant vous travaillez avec une entreprise à Freedonia. L'identifiant de la société franconienne comprend jusqu'à 16 caractères. Vous devez agrandir la clé primaire de l'ID de société (également les champs de clé étrangère dans les commandes, les problèmes, les transferts d'argent, etc.), en ajoutant un champ Pays dans la clé primaire (également dans les clés étrangères). Aie! Guerre civile à Freedonia, c'est s divisé en trois pays. Le nom du pays de votre associé doit être remplacé par le nouveau; mises à jour en cascade à la rescousse. BTW, quelle est votre clé primaire? (Pays, CompanyID) ou (CompanyID, Country)? Ce dernier facilite les jointures, le premier évite un autre index (ou peut-être plusieurs, si vous voulez que vos commandes soient également regroupées par pays).

Tout cela n'est pas une preuve, mais une indication qu'une clé de substitution pour identifier de manière unique une ligne pour toutes les utilisations, y compris les opérations de jointure, est préférable à une clé métier.

Je déteste les clés de substitution en général. Ils ne doivent être utilisés que lorsqu'aucune clé naturelle de qualité n'est disponible. Il est plutôt absurde quand on y pense, de penser que l'ajout de données sans signification à votre tableau pourrait améliorer les choses.

Voici mes raisons:

1. Lorsque vous utilisez des clés naturelles, les tables sont regroupées de la manière dont elles sont le plus souvent recherchées, accélérant ainsi les requêtes.

2. Lorsque vous utilisez des clés de substitution, vous devez ajouter des index uniques sur les colonnes de clé logique. Vous devez toujours empêcher les données en double logique. Par exemple, vous ne pouvez pas autoriser deux organisations portant le même nom dans votre table d'organisation même si le pk est une colonne d'ID de substitution.

3. Lorsque des clés de substitution sont utilisées comme clé primaire, il est beaucoup moins clair quelles sont les clés primaires naturelles. Lors du développement, vous voulez savoir quel ensemble de colonnes rend la table unique.

4. Dans une à plusieurs chaînes de relations, les chaînes de clés logiques. Ainsi, par exemple, les organisations ont de nombreux comptes et les comptes ont de nombreuses factures. Ainsi, la clé logique de l'organisation est OrgName. La clé logique des comptes est OrgName, AccountID. La clé logique de Invoice est OrgName, AccountID, InvoiceNumber.

   Lorsque des clés de substitution sont utilisées, les chaînes de clés sont tronquées en ayant uniquement une clé étrangère pour le parent immédiat. Par exemple, la table Facture n'a pas de colonne OrgName. Il n'a qu'une colonne pour le AccountID. Si vous souhaitez rechercher des factures pour une organisation donnée, vous devrez rejoindre les tables Organisation, Compte et Facture. Si vous utilisez des clés logiques, vous pouvez interroger directement la table d'organisation.

5. Le stockage des valeurs de clé de substitution des tables de recherche entraîne le remplissage des tables avec des entiers sans signification. Pour afficher les données, des vues complexes doivent être créées qui se joignent à toutes les tables de recherche. Une table de recherche est censée contenir un ensemble de valeurs acceptables pour une colonne. Il ne doit pas être codifié en stockant une clé de substitution d'entier à la place. Il n'y a rien dans les règles de normalisation qui suggère que vous devriez stocker un entier de substitution au lieu de la valeur elle-même.

6. J'ai trois livres de bases de données différents. Aucun d'entre eux n'utilise des clés de substitution.

Je veux partager mon expérience avec vous sur cette guerre sans fin: D sur le dilemme clé naturel vs substitut. Je pense que les clés de substitution (artificielles auto-générées) et les clés naturelles (composées de colonnes avec une signification de domaine) ont des avantages et des inconvénients . Donc, selon votre situation, il peut être plus pertinent de choisir une méthode ou une autre.

Comme il semble que beaucoup de gens présentent les clés de substitution comme la solution presque parfaite et les clés naturelles comme la peste, je me concentrerai sur les arguments de l'autre point de vue:

Inconvénients des clés de substitution

Les clés de substitution sont:

1. Source de problèmes de performances:
   • Ils sont généralement mis en œuvre à l'aide de colonnes auto-incrémentées, ce qui signifie:
     • Un aller-retour vers la base de données chaque fois que vous voulez obtenir un nouvel identifiant (je sais que cela peut être amélioré en utilisant la mise en cache ou des algorithmes similaires à [seq] hilo, mais ces méthodes ont toujours leurs propres inconvénients).
     • Si un jour vous avez besoin de déplacer vos données d'un schéma à un autre (cela arrive assez régulièrement dans mon entreprise au moins), vous risquez de rencontrer des problèmes de collision d'identité. Et oui, je sais que vous pouvez utiliser des UUID, mais ces derniers nécessitent 32 chiffres hexadécimaux! (Si vous vous souciez de la taille de la base de données, cela peut être un problème).
     • Si vous utilisez une séquence pour toutes vos clés de substitution, vous vous retrouverez certainement avec une contention sur votre base de données.
2. Sujet aux erreurs. Une séquence a une limite max_value donc - en tant que développeur - vous devez faire attention aux points suivants:
   • Vous devez cycle votre séquence (lorsque la valeur max est atteinte, elle revient à 1,2, ...).
   • Si vous utilisez la séquence comme ordre (au fil du temps) de vos données, vous devez gérer le cas du cyclisme (la colonne avec l'ID 1 peut être plus récente que la ligne avec l'ID max-value - 1).
   • Assurez-vous que votre code (et même vos interfaces client qui ne devraient pas se produire car il est supposé être un ID interne) prend en charge les entiers 32b / 64b que vous avez utilisés pour stocker vos valeurs de séquence.
3. Ils ne garantissent pas des données non dupliquées. Vous pouvez toujours avoir 2 lignes avec toutes les mêmes valeurs de colonne mais avec une valeur générée différente. Pour moi, c'est LE problème des clés de substitution du point de vue de la conception de bases de données.
4. Plus sur Wikipedia ...

Mythes sur les clés naturelles

1. Les clés composites sont moins inefficaces que les clés de substitution. Non! Cela dépend du moteur de base de données utilisé:
   • Oracle
   • MySQL
2. Les clés naturelles n'existent pas dans la vraie vie. Désolé mais ils existent! Dans l'industrie aéronautique, par exemple, le tuple suivant sera toujours unique par rapport à un vol régulier donné (compagnie aérienne, date de départ, numéro de vol, suffixe opérationnel). Plus généralement, lorsqu'un ensemble de données d'entreprise est garanti comme étant unique par une norme donnée , cet ensemble de données est un [bon] candidat clé naturelle.
3. Les clés naturelles «polluent le schéma» des tables enfants. Pour moi, c'est plus un sentiment qu'un vrai problème. Avoir une clé primaire de 4 colonnes de 2 octets chacune peut être plus efficace qu'une seule colonne de 11 octets. De plus, les 4 colonnes peuvent être utilisées pour interroger directement la table enfant (en utilisant les 4 colonnes d'une clause where) sans se joindre à la table parent.

Conclusion

Utilisez des clés naturelles lorsqu'il est pertinent de le faire et utilisez des clés de substitution lorsqu'il est préférable de les utiliser.

J'espère que cela a aidé quelqu'un!

Utilisez toujours une clé qui n'a aucune signification commerciale. C'est juste une bonne pratique.

EDIT: J'essayais de trouver un lien vers celui-ci en ligne, mais je ne pouvais pas. Cependant, dans «Patterns of Enterprise Archtecture» [Fowler], il a une bonne explication de la raison pour laquelle vous ne devriez pas utiliser autre chose qu'une clé sans autre signification que d'être une clé. Cela se résume au fait qu'il ne devrait avoir qu'un seul emploi et un seul emploi.

Les clés de substitution sont très pratiques si vous prévoyez d'utiliser un outil ORM pour gérer / générer vos classes de données. Bien que vous puissiez utiliser des clés composites avec certains des mappeurs les plus avancés (lire: hibernate), cela ajoute une certaine complexité à votre code.

(Bien sûr, les puristes des bases de données soutiendront que même la notion de clé de substitution est une abomination.)

Je suis fan de l'utilisation des uids pour les clés de substitution, le cas échéant. Le principal avantage avec eux est que vous connaissez la clé à l'avance, par exemple, vous pouvez créer une instance d'une classe avec l'ID déjà défini et garanti unique alors qu'avec, par exemple, une clé entière, vous devrez par défaut à 0 ou - 1 et mettez à jour à une valeur appropriée lorsque vous enregistrez / mettez à jour.

Les UID ont des pénalités en termes de recherche et de vitesse de jointure, donc cela dépend de l'application en question pour savoir s'ils sont souhaitables.

À mon avis, l'utilisation d'une clé de substitution est préférable car il n'y a aucune chance qu'elle change. Presque tout ce que je peux penser et que vous pourriez utiliser comme clé naturelle pourrait changer (avertissement: pas toujours vrai, mais généralement).

Un exemple pourrait être une base de données de voitures - à première vue, vous pourriez penser que la plaque d'immatriculation pourrait être utilisée comme clé. Mais ceux-ci pourraient être modifiés, ce serait donc une mauvaise idée. Vous ne voudriez pas vraiment le savoir après la sortie de l'application, quand quelqu'un vient vous voir pour savoir pourquoi il ne peut pas changer sa plaque d'immatriculation en une nouvelle et brillante personnalisée.

Utilisez toujours une seule colonne, clé de substitution si possible. Cela rend les jointures ainsi que les insertions / mises à jour / suppressions beaucoup plus propres, car vous n'êtes responsable que du suivi d'un seul élément d'information pour maintenir l'enregistrement.

Ensuite, si nécessaire, empilez vos clés d'entreprise sous forme de contraintes ou d'index uniques. Cela gardera l'intégrité de vos données intacte.

La logique métier / les clés naturelles peuvent changer, mais la clé physique d'une table ne doit JAMAIS changer.

Dans un scénario d'entrepôt de données, je pense qu'il est préférable de suivre le chemin de la clé de substitution. Deux raisons:

• Vous êtes indépendant du système source, et les modifications apportées, comme une modification du type de données, ne vous affecteront pas.
• Votre DW aura besoin de moins d'espace physique puisque vous n'utiliserez que des types de données entiers pour vos clés de substitution. Vos index fonctionneront également mieux.

Les clés de substitution peuvent être utiles lorsque les informations commerciales peuvent changer ou être identiques. Les noms commerciaux n'ont pas à être uniques dans tout le pays, après tout. Supposons que vous traitez avec deux entreprises nommées Smith Electronics, une au Kansas et une au Michigan. Vous pouvez les distinguer par adresse, mais cela changera. Même l'État peut changer; Et si Smith Electronics de Kansas City, Kansas traversait la rivière jusqu'à Kansas City, Missouri? Il n'y a pas de moyen évident de garder ces entreprises distinctes avec des informations de clé naturelle, donc une clé de substitution est très utile.

Considérez la clé de substitution comme un numéro ISBN. Habituellement, vous identifiez un livre par titre et auteur. Cependant, j'ai deux livres intitulés "Pearl Harbor" de HP Willmott, et ce sont définitivement des livres différents, pas seulement des éditions différentes. Dans un cas comme celui-là, je pourrais me référer à l'apparence des livres, ou le plus tôt ou le plus tard, mais c'est aussi bien que j'ai l'ISBN sur lequel me rabattre.

Pour rappel, il n'est pas recommandé de placer des index clusterisés sur des clés de substitution aléatoires, c'est-à-dire des GUID qui lisent XY8D7-DFD8S, car SQL Server n'a pas la capacité de trier physiquement ces données. Vous devez à la place placer des index uniques sur ces données, bien qu'il puisse également être avantageux d'exécuter simplement le profileur SQL pour les opérations de la table principale, puis de placer ces données dans l'assistant de réglage du moteur de base de données.

Voir le fil de discussion @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

Cas 1: votre table est une table de recherche avec moins de 50 types (insertions)

Utilisez des clés professionnelles / naturelles . Par exemple:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Cas 2: votre table est une table avec des milliers d'inserts

Utilisez des clés de substitution / auto-incrémentation . Par exemple:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

Dans le premier cas:

• Vous pouvez sélectionner tous les programmeurs de la table PEOPLE sans utiliser de jointure avec la table JOB, mais uniquement avec: "SELECT * FROM PEOPLE WHERE JOBCODE = 'PRG'"

Dans le second cas:

• Vos requêtes de base de données sont plus rapides car votre clé primaire est un entier
• Vous n'avez pas besoin de vous soucier de trouver la prochaine clé unique car la base de données elle-même vous donne le prochain auto-incrémentation.

C'est l'un de ces cas où une clé de substitution a toujours du sens. Il y a des cas où vous choisissez ce qui est le mieux pour la base de données ou ce qui est le mieux pour votre modèle d'objet, mais dans les deux cas, l'utilisation d'une clé ou d'un GUID sans signification est une meilleure idée. Cela rend l'indexation plus facile et plus rapide, et c'est une identité pour votre objet qui ne change pas.

Cheval pour les cours. Pour déclarer mon parti pris; Je suis d'abord développeur, donc je suis principalement soucieux de donner aux utilisateurs une application fonctionnelle.

J'ai travaillé sur des systèmes avec des clés naturelles et j'ai dû passer beaucoup de temps à m'assurer que les changements de valeur se répercuteraient.

J'ai travaillé sur des systèmes avec uniquement des clés de substitution, et le seul inconvénient est le manque de données dénormalisées pour le partitionnement.

La plupart des développeurs PL / SQL traditionnels avec lesquels j'ai travaillé n'aimaient pas les clés de substitution en raison du nombre de tables par jointure, mais nos bases de données de test et de production n'ont jamais fait peur; les jointures supplémentaires n'affectaient pas les performances de l'application. Avec les dialectes de base de données qui ne prennent pas en charge les clauses telles que "X inner join Y on Xa = Yb", ou les développeurs qui n'utilisent pas cette syntaxe, les jointures supplémentaires pour les clés de substitution rendent les requêtes plus difficiles à lire et plus longues à taper et vérifier: voir le post de @Tony Andrews. Mais si vous utilisez un ORM ou tout autre framework de génération SQL, vous ne le remarquerez pas. La saisie tactile atténue également.

Peut-être pas tout à fait pertinent pour ce sujet, mais un mal de tête que j'ai face aux clés de substitution. L'analyse pré-livrée d'Oracle crée des SKs générés automatiquement sur toutes ses tables de dimension dans l'entrepôt, et les stocke également sur les faits. Ainsi, chaque fois qu'ils (dimensions) doivent être rechargés au fur et à mesure que de nouvelles colonnes sont ajoutées ou doivent être remplies pour tous les éléments de la dimension, les SK attribués lors de la mise à jour font que les SK ne sont pas synchronisés avec les valeurs d'origine stockées sur le fait, forçant un rechargement complet de toutes les tables de faits qui s'y rattachent. Je préférerais que même si le SK était un nombre sans signification, il y aurait un moyen qu'il ne puisse pas changer pour les disques originaux / anciens. Comme beaucoup le savent, le prêt à l'emploi répond rarement aux besoins d'une organisation et nous devons constamment personnaliser. Nous avons maintenant 3 ans de données dans notre entrepôt, et les recharges complètes à partir des systèmes Oracle Financial sont très importantes. Donc dans mon cas, ils ne sont pas générés à partir de la saisie de données, mais ajoutés dans un entrepôt pour aider à rendre compte des performances. Je comprends, mais les nôtres changent et c'est un cauchemar.

Dans le cas d'une base de données ponctuelle, il est préférable d'avoir une combinaison de clés de substitution et naturelles. Par exemple, vous devez suivre les informations d'un membre pour un club. Certains attributs d'un membre ne changent jamais. par exemple, date de naissance, mais le nom peut changer. Créez donc une table Member avec une clé de substitution member_id et ayez une colonne pour DOB. Créez une autre table appelée nom de la personne et avez des colonnes pour member_id, member_fname, member_lname, date_updated. Dans cette table, la clé naturelle serait member_id + date_updated.