Clé primaire ou Unique Contrainte?
Je suis actuellement à la conception d'une nouvelle base de données. À l'école, nous avons toujours appris à mettre une clé primaire de chaque table.
J'ai lu beaucoup d'articles/discussions/groupes de discussion posts disant que c'est mieux d'utiliser la contrainte unique (aka index unique pour certains db) à la place de PK.
Quel est votre point de vue?
Vous devez vous connecter pour publier un commentaire.
Pouvez-vous donner 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 conception fondamentale de la fonctionnalité de bases de données relationnelles.
À l'aide UNIQUE pour servir le même but semble vraiment hackish pour moi. Quel est leur raison d'être?
Edit: Mon attention viens juste de revenir à cette vieille réponse. Peut-être que la discussion que vous lisez concernant PK vs UNIQUE traitées avec les gens à faire quelque chose d'un penalty dans le seul but de faire respecter l'unicité sur elle. La réponse à cette question est, Si c'EST une clé, puis en faire la clé, ou de le rendre UNIQUE.
Une Clé Primaire est vraiment juste une candidat à la clé qui ne permet pas la valeur NULL. En tant que tel, dans SQL termes - c'est pas différent de toute autre clé unique.
Cependant, pour notre non-théorique du SGBDR, vous devez avoir une Clé Primaire - je n'ai jamais entendu dire le contraire. Si la Clé Primaire est un clé de substitution, alors vous devriez aussi des contraintes uniques sur les naturel clé(s).
Les bits importants à pied, c'est que vous devriez avoir les contraintes uniques sur tous le candidat (qu'ils soient naturels ou de substitution) de la télécommande. Vous devez ensuite choisir celui qui est le plus facile de référence dans un Clé Étrangère à votre Clé Primaire*.
Vous devriez également avoir une index cluster*. cette pourrait être votre Clé Primaire, ou une clé naturelle - mais il n'est pas nécessaire d'être. Vous devriez choisir votre index cluster basé sur l'utilisation des requêtes de la table. En cas de doute, la Clé Primaire n'est pas un mauvais premier choix.
Si techniquement, il est seulement nécessaire de se référer à une clé unique dans une relation de clé étrangère, il est admis à la pratique de grandement faveur de la clé primaire. En fait, je ne serais pas surpris si certains SGBDR autoriser uniquement la clé primaire de références.
Edit: Il a été souligné que l'Oracle du terme de "cluster de la table" et "index cluster" sont différents de Sql Server. L'équivalent de ce que je parle de l'Oracle-ese est un Index Ordonné De Table et il est recommandé pour OLTP tables - qui, je pense, serait le principal objet de questions. Je suppose que si vous êtes responsable d'un grand entrepôt de données OLAP, vous devez déjà avoir votre propre opinion sur la base de données de conception et d'optimisation.
Une clé primaire est juste une clé candidate (contrainte d'unicité) sort particulier de traitement (création automatique d'index, etc).
Je pense que les gens qui les soutiennent contre eux ne vois aucune raison de traiter une touche différemment de l'autre. C'est là où j'en suis.
[Edit] Apparemment, je ne peux pas commenter, même sur ma propre réponse sans de 50 points.
@chris: je ne pense pas qu'il n'y a aucun mal. "Clé primaire" est vraiment juste sucre syntaxique. Je les utilise tout le temps, mais je ne pense pas que vous en avez besoin. Un unique clé est nécessaire, oui, mais pas nécessairement d'une Clé Primaire.
Il serait très rare de dénormalisation et qui vous voulez avoir une table sans clé primaire. Les clés primaires des contraintes uniques automatiquement juste de par leur nature, comme le PK.
Une contrainte unique peut être utilisé lorsque vous souhaitez garantir l'unicité dans une colonne en PLUS de la clé primaire.
La règle de toujours avoir un PK est un bon.
http://msdn.microsoft.com/en-us/library/ms191166.aspx
Vous devriez toujours avoir une clé primaire.
Cependant je soupçonne votre question est libellée peu trompeur, et vous fait dire demander si la clé primaire doit toujours être un numéro généré automatiquement (aussi connu comme la clé de substitution), ou certaines champ unique qui est réel de données significatives (aussi connu comme la clé naturelle), comme le SSN pour les personnes, ISBN pour les livres et ainsi de suite.
Cette question est une vieille guerre de religion dans le champ DB.
De mon point de vue est que les touches sont préférables si en effet, ils sont uniques et ne changent jamais. Cependant, vous devez être prudent, même quelque chose d'apparemment stable personnes SSN peut changer dans certaines circonstances.
Clés primaires doivent être utilisés dans des situations où vous serez en établissant des relations à partir de cette table, et d'autres tables de référence de cette valeur. Cependant, selon la nature de la table et les données que vous pensez de l'application de la contrainte unique, vous pouvez être en mesure d'utiliser ce champ comme un élément naturel de la clé primaire plutôt que d'avoir à établir une clé de substitution. Bien sûr, porteuse vs les clefs naturelles sont une toute autre discussion. 🙂
Unique touches peuvent être utilisées si il n'y aura pas de relation établie entre ce tableau et les autres tables. Par exemple, une table qui contient une liste d'adresses e-mail valides qui seront comparés avant l'insertion d'un nouvel enregistrement d'utilisateur ou quelque chose du genre. Ou uniques, et les touches peuvent être utilisées lorsque vous avez des valeurs dans une table qui a une clé primaire, mais doit aussi être absolument unique. Par exemple, si vous avez une table d'utilisateurs qui a un nom d'utilisateur. Vous ne voulez pas utiliser le nom d'utilisateur de la clé primaire, mais il doit également être unique pour être utilisé pour connecter des fins.
À moins que la table est une table temporaire en scène les données pendant que vous travaillez, vous voulez toujours mettre une clé primaire sur la table, et voici pourquoi:
1 - une contrainte unique peut autoriser les valeurs null, mais une clé primaire jamais autorise les valeurs null. Si vous exécutez une requête avec une jointure sur des colonnes avec des valeurs null, vous éliminer ces lignes à partir de la base de données obtenue parce que null n'est pas égal à null. C'est de cette façon, même les grandes entreprises peuvent faire des erreurs de comptabilité et d'avoir à retraiter leurs profits. Leurs requêtes à ne pas montrer certaines lignes ont été inclus dans le total car il y avait des valeurs null dans certaines colonnes de leur index unique. Shoulda utilisé une clé primaire.
2 - un index unique sera automatiquement placé sur la clé primaire, de sorte que vous n'avez pas à en créer un.
3 - la plupart des moteurs de base de données sera automatiquement mis un index cluster sur la clé primaire, faire des requêtes plus rapides car les lignes sont stockés de manière contiguë dans les blocs de données. (Cela peut être modifié à la place de l'index cluster sur un autre indice qui permettrait d'accélérer les requêtes.) Si une table n'a pas d'index cluster, les lignes ne seront pas stockés de manière contiguë dans les blocs de données, faire des requêtes plus lent, car la tête de lecture/écriture est de parcourir le disque pour récupérer les données.
4 - de nombreux avant la fin des environnements de développement nécessitent une clé primaire pour la mise à jour de la table ou de faire des suppressions.
Nous devons faire une distinction ici entre les constructions logiques et physiques des constructions, et, de même qu'entre la théorie et la pratique.
Pour commencer: à partir d'un point de vue théorique, si vous n'avez pas de clé primaire, vous n'avez pas de table. C'est aussi simple que cela. Donc, votre question n'est pas de savoir si votre table doit avoir une clé primaire (bien sûr, il devrait), mais comment vous l'étiquette à l'intérieur de votre SGBDR.
Au niveau physique, la plupart des Sgbdr mettre en œuvre la contrainte de Clé Primaire comme un Index Unique. Si votre SGBDR est l'un de ceux-ci, il n'y a probablement pas beaucoup de différence pratique entre la désignation d'une colonne comme Clé Primaire, et tout simplement en mettant une contrainte unique sur la colonne. Cependant: l'une de ces options de capture de votre intention, et l'autre ne l'est pas. Ainsi, la décision est un no-brainer.
En outre, certains Sgbdr faire des fonctionnalités supplémentaires disponibles si les Clés Primaires sont correctement étiquetés, tels que les diagrammes, et semi-automatique de clé étrangère-contrainte de soutien.
Quelqu'un qui vous dit à usage Unique à la place les Contraintes de Clés Primaires en règle générale, devrait offrir un joli maudite bonne raison.
le truc, c'est qu'une clé primaire peut être une ou plusieurs colonnes qui identifient de manière unique un enregistrement d'une table, d'où une Contrainte Unique est juste une contrainte sur un terrain qui ne permet qu'une seule instance de chaque élément de données dans une table.
PERSONNELLEMENT, j'utilise soit GUID ou de l'auto-incrémentation BIGINTS (Identité d'Insertion pour SQL SERVER) pour les clés uniques utilisées pour les références croisées entre mes tables. Alors, je vais utiliser d'autres données pour permettre à l'utilisateur de sélectionner des enregistrements spécifiques.
Par exemple, je vais avoir une liste des employés, et ont un GUID associé à chaque enregistrement que j'utilise en coulisses, mais lorsque l'utilisateur sélectionne un employé, ils font leur choix en fonction hors des champs suivants: Nom + Prénom + EmployeeNumber.
Ma clé primaire dans ce scénario est le Nom + Prénom + EmployeeNumber tandis que la clé unique est associé le GUID.
je suppose que la seule question ici est le même vieux débat "naturel vs les clés de substitution", parce que les index uniques et pks sont la même chose.
de la traduction:
postes en disant que c'est mieux d'utiliser des clés au lieu de clé de substitution
J'ai l'habitude d'utiliser les deux PK et UNIQUE CLÉ. Parce que même si vous ne désigne pas PK dans votre schéma, on est toujours généré en interne. C'est vrai à la fois pour SQL Server 2005 et MySQL 5.
Mais je n'utilise pas le PK colonne dans mon Sql. Il est pour fins de gestion comme DELETEing quelques lignes erronées, de trouver des écarts entre les valeurs de clé primaire si elle est définie sur AUTO INCRÉMENT. Et, il est logique d'avoir un PK comme des nombres, pas un ensemble de colonnes ou des tableaux de char.
J'ai beaucoup écrit sur ce sujet: si vous lisez rien de mine d'être clair que j'étais probablement en se référant spécifiquement à Jet une.k.un. MS Access.
Dans le Jet, les tables sont physiquement commandé sur la CLÉ PRIMAIRE à l'aide d'un non-maintenu index cluster (cluster sur les compacts). Si la table n'a pas PK mais n'ont candidat clés définis à l'aide de contraintes UNIQUES sur not NULL colonnes, alors que le moteur va choisir un pour l'index cluster (si votre table n'a pas d'index cluster, puis il est appelé un tas, sans doute pas une table à tous!) Comment fonctionne le moteur de choisir un candidat à la clé? Peut-il choisir un qui comprend nullable colonnes? Je ne sais vraiment pas. Le point est que, dans le Jet de la seule manière explicite de la spécification de l'index cluster pour le moteur est à l'utilisation de la CLÉ PRIMAIRE. Il y a bien sûr d'autres utilisations pour le PK dans le Jet d'exemple, il sera utilisé comme clé si l'on est omis à partir d'une CLÉ ÉTRANGÈRE dans la déclaration de SQL DDL mais encore une fois pourquoi ne pas être explicite.
Le problème avec le Jet est que la plupart des gens qui créer des tables sont pas au courant ou ne se préoccupe pas des index en cluster. En fait, la plupart des utilisateurs (je pari) a mis un autoincrement Numéroauto colonne sur chaque table et définir la CLÉ PRIMAIRE uniquement sur cette colonne, tout en omettant de mettre des contraintes uniques sur la clé naturelle et candidat touches (si une colonne d'auto-incrémentation peut en fait être considérée comme une clé sans l'exposer à des utilisateurs finaux est une autre discussion en elle-même). Je n'entrerai pas dans les détails sur les index cluster ici, mais il suffit de dire que l'OMI une seule colonne d'auto-incrémentation est rarement un choix idéal.
Ce que vous SQL moteur, le choix de la CLÉ PRIMAIRE est arbitraire et spécifique au moteur. Habituellement le moteur va appliquer une signification particulière pour le PK, donc vous devriez trouver ce que c'est et l'utiliser à votre avantage. J'encourage les gens à utiliser not NULL UNIQUE contraintes dans l'espoir qu'ils vont donner plus de considération à tous les candidats touches, surtout quand ils ont choisi d'utiliser les "numéroauto" colonnes qui (devrait) n'ont pas de sens dans le modèle de données. Mais je préfère folk choisir un bien considéré comme essentiel et utilisé de CLÉ PRIMAIRE plutôt que de le mettre sur l'auto-incrémentation de la colonne de sortir de l'habitude.
Doit toutes les tables ont un PK? Je dis oui parce que sinon, les moyens à tout le moins, vous êtes absent dehors sur un léger avantage le moteur offre la PK et, au pire, vous n'avez pas l'intégrité des données.
BTW Chris OC qui fait un bon point ici sur l'temporelle des tables, qui nécessitent séquencé clés primaires (en minuscules) qui ne peuvent être mis en œuvre par le biais de simples contraintes de CLÉ PRIMAIRE (SQL mots-clés en majuscules).
CLÉ PRIMAIRE
1. Null
Il n'autorise pas les valeurs Null. De ce fait nous nous référons CLÉ PRIMAIRE =
CLÉ UNIQUE + de CONTRAINTE not Null.
2. L'INDICE de
Par défaut, il ajoute un index cluster.
3. LIMITE
Une table peut avoir qu'une seule Colonne de CLÉ PRIMAIRE[s].
CLÉ UNIQUE
1. Null
Permet de Nulle valeur. Mais une seule valeur Null.
2. L'INDICE de
Par défaut, il ajoute un UNIQUE index non ordonné en clusters.
3. LIMITE
Une table peut avoir plus d'une Colonne de Clé UNIQUE[s].
Si vous prévoyez sur l'utilisation de LINQ-to-SQL, vos tables exigera des Clés Primaires si vous envisagez sur l'exécution des mises à jour, et ils nécessitent une
timestampcolonne si vous prévoyez de travailler dans un environnement déconnecté (comme le passage d'un objet par l'intermédiaire d'un service WCF application).Si vous le souhaitez .NET, PK et FK sont vos amis.
Je soutiens que vous pouvez avoir besoin à la fois. Les clés primaires, par nature, doivent être uniques et non pas les valeurs null. Ils sont souvent les clés de substitution comme les entiers de créer plus rapidement des jointures de caractère champs et surtout que plusieurs personnage rejoint. Cependant, comme ce sont souvent générés automatiquement, ils ne garantissent pas l'unicité de l'enregistrement de données à l'exclusion de l'id lui-même. Si votre table a une clé naturelle qui doit être unique, vous devez disposer d'un index unique sur elle pour empêcher que les données d'entrée de doublons. C'est une base de données de l'intégrité exigence.
Édité à ajouter: C'est aussi un problème réel, que les données du monde réel n'a souvent pas une clé naturelle que vraiment garantit l'unicité dans une table normalisée de la structure, surtout si la base de données est axée sur les gens. Noms de, même nom, l'adresse et le numéro de téléphone combiné (pense que le père et le fils dans la même pratique médicale) ne sont pas nécessairement unique.
Je pensais de ce problème moi-même. Si vous êtes uniques, vous aurez du mal à la 2. NF. Selon cette non-pk-attribut doit être en fonction du PK. La paire d'attributs de cette contrainte unique sont à considérer comme faisant partie de la PK.
désolé pour la réponse à cette 7 ans plus tard, mais ne voulait pas démarrer une nouvelle discussion.