Clé primaire ou contrainte unique ?

Question

Je suis actuellement en train de concevoir une toute nouvelle base de données. À l'école, nous avons toujours appris à mettre une clé primaire dans chaque table.

J'ai lu beaucoup d'articles/discussions/postes de groupes de discussion disant qu'il est préférable d'utiliser la contrainte unique (aka index unique pour certains db) au lieu de PK.

Quel est votre point de vue ?

Answer 1

Une clé primaire est en fait juste un clé du candidat qui n'autorise pas le NULL. En tant que telle, en termes de SQL, elle n'est pas différente de toute autre clé unique.

Cependant, pour nos SGBDR non théoriques, vous devez avoir une clé primaire - je n'ai jamais entendu dire le contraire. Si cette clé primaire est un clé de substitution alors vous devriez également ont des contraintes uniques sur les clé(s) naturelle(s) .

Ce qu'il est important de retenir, c'est que vous devez avoir des contraintes uniques en matière de tous les clés du candidat (naturel ou de substitution). Vous devez ensuite choisir celle qui est la plus facile à référencer dans une clé de type Clé étrangère pour être votre clé primaire*.

Vous devriez également disposer d'un indice groupé *. ce podría être votre clé primaire, ou une clé naturelle - mais il n'est pas nécessaire que ce soit l'une ou l'autre. Vous devez choisir votre index en grappe en fonction de l'utilisation des requêtes de la table. En cas de doute, la clé primaire n'est pas un mauvais choix.

• Bien qu'il ne soit techniquement nécessaire de se référer qu'à une clé unique dans une relation de type clé étrangère, la pratique standard acceptée est la suivante grandement favoriser la clé primaire. En fait, je ne serais pas surpris que certains SGBDR n'autorisent que les références aux clés primaires.

• Edit : On m'a fait remarquer que les termes Oracle de "clustered table" et "clustered index" sont différents de ceux de Sql Server. L'équivalent de ce dont je parle en Oracle-ese est un Table ordonnée par index et il est recommandé pour les tables OLTP - ce qui, je pense, serait l'objet principal des questions de l'OS. Je suppose que si vous êtes responsable d'un grand entrepôt de données OLAP, vous devez déjà avoir vos propres opinions sur la conception et l'optimisation des bases de données.

Answer 2

Pouvez-vous fournir les références de ces articles ?

Je ne vois aucune raison de changer les méthodes éprouvées. Après tout, les clés primaires sont une caractéristique fondamentale de la conception des bases de données relationnelles.

L'utilisation d'UNIQUE pour atteindre le même objectif me semble être un véritable piratage. Quel est leur raisonnement ?

Edit : Mon attention vient d'être attirée à nouveau sur cette ancienne réponse. Peut-être que la discussion que vous avez lue au sujet de PK vs. UNIQUE concernait des personnes faisant de quelque chose un PK dans le seul but d'en imposer l'unicité. La réponse à cette question est : si c'est une clé, alors faites-en une clé, sinon faites-en une UNIQUE.

Answer 3

Une clé primaire est simplement une clé candidate (contrainte unique) qui fait l'objet d'un traitement spécial (création automatique d'index, etc.).

Je m'attends à ce que les personnes qui s'y opposent ne voient aucune raison de traiter une clé différemment d'une autre. C'est ma position.

[Edit] Apparemment je ne peux pas commenter même ma propre réponse sans avoir 50 points.

@ chris : Je ne pense pas qu'il y ait de mal. "Primary Key" est vraiment juste un sucre syntaxique. Je les utilise tout le temps, mais je ne pense certainement pas qu'elles soient nécessaires. Un unique clé est nécessaire, oui, mais pas nécessairement une clé primaire.

Answer 4

Il serait très rare qu'une dénormalisation vous incite à avoir une table sans clé primaire. Les clés primaires ont des contraintes uniques automatiquement, juste par leur nature de clé primaire.

Une contrainte unique est utilisée lorsque vous voulez garantir l'unicité d'une colonne en PLUS de la clé primaire.

La règle de toujours avoir un PK est une bonne règle.

http://msdn.microsoft.com/en-us/library/ms191166.aspx

Answer 5

Vous devez toujours ont une clé primaire.

Cependant, je soupçonne que votre question est formulée de manière un peu trompeuse, et que vous voulez en fait demander si la clé primaire doit toujours être un numéro généré automatiquement (également connu sous le nom de clé de substitution), ou un champ unique qui est une donnée significative réelle (également connu sous le nom de clé naturelle), comme le SSN pour les personnes, l'ISBN pour les livres, etc.

Cette question est une vieille guerre de religion dans le domaine de la DB.

Selon moi, les clés naturelles sont préférables si elles sont effectivement uniques et ne changent jamais. Cependant, il faut être prudent, car même un élément apparemment stable comme le SSN d'une personne peut changer dans certaines circonstances.