Je sais qu'il ne peut pas y avoir plus d'une clé primaire dans une table, mais quelle est la raison technique?
12 Réponses :
clé primaire est généralement équivalent à index unique non null . Donc, vous pouvez efficacement avoir plusieurs "clés primaires" sur une seule table.
Fermer mais pas de cigare. Si une table présente plusieurs candidats principaux, le contenu de chaque colonne (ligne) ne sont pas dupliqués et que tout «pourrait être sélectionné» comme clé primaire. AFAIK, la seule raison réelle qu'une seule clé primaire peut être définie est que, par la SP parmi d'autres, utilisera la clé principale définie pour créer un index clustered ... Le tableau est physiquement trié par la clé primaire. Contrainte [PK_TABLE_COLUMN] Touche principale regroupée. D'autres candidats doivent utiliser votre contrainte d'index unique pour garantir l'intégrité. Votre code devrait ensuite utiliser la clé primaire définie pour les recherches d'efficacité.
Eh bien, ça s'appelle "primaire" pour une raison. Comme dans, sa clé unique utilisée pour identifier de manière unique l'enregistrement ... et là " peut être un seul ".
Vous pouvez certainement mimick une deuxième clé "primaire" en ayant un index placé sur un ou plusieurs autres champs unique mais aux fins de votre serveur de base de données, il est généralement nécessaire que votre clé ISN 'T assez unique pour traverser des serveurs de bases de données dans une situation de réplication de fusion. (c.-à-d.: Multi Master).
Je vous évite deux fois. Une fois pour la réponse et la deuxième fois pour le lien Highlander;)
@inflagranti: Il suffit de ne pas cliquer deux fois;)
+1 pour référence Highlander ... et me rend compte qu'ils réactivent l'original de 1986, prévu pour cette année. Dieu, quand allons-nous voir le rassemblement ???!
Vous pouvez également avoir une référence de lotr. La seule clé pour les gouverner tous !!
Parce que la "clé primaire" "principale" désigne sa, mmm, singularité (?).
Mais si vous avez besoin de plus, vous pouvez définir des touches uniques qui ont un même comportement.
La raison technique est qu'il ne peut y avoir qu'une seule Cependant, une clé primaire
tiré directement de Donc :
Vous ne pouvez avoir qu'une seule clé primaire, mais vous pouvez avoir plusieurs colonnes dans votre clé primaire.
Vous pouvez également avoir des index uniques sur votre table, ce qui fonctionnera un peu comme une clé primaire en ce sens qu'elles appliqueront des valeurs uniques et accéléreront l'interrogation de ces valeurs.
Il s'agit également généralement de la clé pour laquelle l'index contient les données réelles qui y sont jointes, c'est-à-dire que les données sont stockées avec l'index de clé primaire. D'autres indices ne contiennent que les données indexées, et peut-être certaines colonnes incluses.
La clé principale est la clé qui identifie de manière unique l'enregistrement.
Je ne sais pas si vous demandez si vous demandez si un) il peut y avoir une clé primaire unique couvrant plusieurs colonnes, ou b) si vous pouvez avoir plusieurs clés qui identifient de manière unique l'enregistrement.
Le premier est possible, appelé clé primaire composite.
La seconde est possible aussi, mais un seul est appelé la clé primaire.
La clé primaire nous permet d'identifier de manière unique chaque enregistrement dans la table. Vous pouvez avoir 2 clés primaires dans une table, mais elles s'appellent des clés principales composites. "Lorsque vous définissez plus d'une colonne comme clé primaire sur une table, elle s'appelle une clé primaire composite."
"Une clé primaire peut avoir plusieurs colonnes" et "vous pouvez avoir deux clés primaires dans une table" sont deux choses très différentes. Le premier est vrai; La seconde est fausse, que vous le regardiez d'un point de vue relationnel ou d'un point de vue SQL.
La clé principale est celle (d'éventuellement de nombreux) identifiants uniques d'une rangée particulière dans une table. Les autres identifiants uniques, qui n'ont pas été désignés comme le primaire , sont donc souvent présentés comme des index uniques secondaires.
Une clé primaire définit l'unicité de l'enregistrement. Avoir deux mesures différentes de l'unicité peuvent être problématiques. Par exemple, si vous avez des touches principales A et B et que vous insérez des enregistrements dans lesquels A est identique et B est différent, ces enregistrements sont-ils identiques ou différents? Si vous les considérez différemment, faites votre principale composite d'A et B. Si vous les considérez comme le même enregistrement, utilisez simplement A ou B comme clé primaire.
Une clé primaire est une solution pour identifier de manière unique des lignes. Ce n'est pas le seul moyen, que vous preniez un point de vue relationnel ou un point de vue SQL. Et il est en fait courant que les tables ont plusieurs clés candidates.
En fait e.f.codd (l'inventeur du modèle de base de données relationnelle) [1] a créé le terme "clé primaire" à signifier tout nombre des clés d'une relation - pas seulement. Il a précisé qu'il était tout à fait possible d'avoir plus d'une telle clé. Sa suggestion était que le concepteur de base de données puisse choisir une clé comme identifiant préféré (" la clé primaire ") - mais en principe, c'était facultatif et un tel choix était "arbitraire" (c'était sa parole) . Parce que toutes les clés bénéficient des mêmes propriétés que l'autre, il n'y a pas de besoin fondamental de choisir l'un sur un autre.
plus tard sur [2], quels codd appelé à l'origine des clés primaires sont devenues appelés les clés et la touche unique distinguée car la clé préférée est devenue la clé "primaire". Ce n'était pas vraiment un décalage fondamental, cependant, car une clé principale signifie exactement la même chose qu'une clé candidate. Comme ils sont des concepts équivalents, cela ne signifie pas vraiment quoi que ce soit important lorsque nous disons qu'il ne s'agit que d'une clé primaire. Si vous avez plus d'une clé de candidature, vous pouvez assez raisonnablement appeler plus de l'un d'entre eux «primaire» si vous préférez, car il n'aboutit aucune différence logique ou pratique pour la signification et la fonction de la base de données.
Il a été discuté (par moi entre autres) que l'idée de désigner une clé par table en tant que "primaire" est totalement superflue et parfois une hurglie positive à une bonne compréhension de la conception de la base de données et de la plantation de données. Cependant, le concept est tellement enraciné que nous sommes probablement bloqués.
La réponse appropriée à votre question est la "convention" et "commodité". Il n'y a pas de bonne raison technique du tout.
[1] Un modèle relationnel de données pour les grandes banques de données partagées (1970)
[2] par ex. dans "Normalisation ultérieure du modèle de base de données relationnelle" (1971)
Une seule clé primaire possible sur la table car la clé principale crée un index en cluster sur la table qui stocke des données physiquement sur le nœud de feuille de manière ordonnée sur la base de cette colonne principale. Si nous essayons de créer une autre clé primaire sur cette table, il y aura un problème majeur lié aux données.Légioncuse ne peut pas stocker les mêmes données de la table en deux commandes différentes.
Une clé primaire crée un index en cluster par défaut (s'il n'y en a pas déjà sur la table), mais vous pouvez forcer cet index à ne pas regrouper à la création de la clé principale avec le mot-clé non clusterné. S'il y a déjà un index en cluster, la clé principale créera par défaut un index non clustered. Aucun problème ne concerne les données que la clé principale et l'index dessert différents objectifs.
Eh bien, cela ne serait plus appelé une clé "primaire" s'il y en avait plus d'un. Quel serait l'avantage d'avoir plus d'une clé primaire quand même?
Imaginez une classe pleine d'écoliers. Enseignant: "Peter, as-tu fait tes devoirs?" Peter Smith: "Oui" Peter Miller: "Non" Peter Jones: "Oui" Enseignant: "Peter Miller, avez-vous fait vos devoirs?" Peter Miller: "Non"