Ce qui ' s la meilleure pratique pour les clés primaires dans les tableaux ?

Question

Lors de la conception des tables, j'ai développé une habitude d'avoir une colonne qui est unique et que je fais de la clé primaire. Ceci est réalisé de trois façons selon les besoins:

1. L'identité colonne de type integer qui auto-incréments.
2. Identifiant Unique (GUID)
3. Un court de caractère(x) ou entier (ou autres relativement faible de type numérique) de la colonne qui peut servir comme un identificateur de ligne de colonne

Numéro 3 serait utilisé pour assez petite recherche, principalement en lecture des tableaux qui pourraient avoir une statique unique chaîne de longueur de code, ou une valeur numérique, par exemple un an ou un autre numéro.

Pour la plupart, toutes les autres tables, à une auto-incrémentation entier ou l'identifiant unique de la clé primaire.

La Question :-)

J'ai récemment commencé à travailler avec des bases de données qui ne sont pas cohérents identificateur de ligne et les clés primaires sont actuellement en cluster à travers les différentes colonnes. Quelques exemples:

• datetime/caractère
• datetime/entier
• datetime/varchar
• char/nvarchar/nvarchar

Est-il valide? J'aurais toujours défini une identité ou l'identifiant unique de la colonne pour ces cas.

En outre, il existe de nombreuses tables sans les clés primaires. Quelles sont les raisons valables, le cas échéant, pour cela?

J'essaie de comprendre pourquoi les tableaux ont été conçus comme ils étaient, et il semble être un gros gâchis pour moi, mais peut-être y avait de bonnes raisons pour cela.

MODIFIER

OK... Wow! Beaucoup de réponses et la discussion. Je suppose que j'ai frappé sur un sujet qui est un peu religieux sans s'en rendre compte. :-)

Une troisième question de faire en sorte de m'aider à déchiffrer les réponses: Dans le cas où plusieurs colonnes sont utilisés pour contenir le composé de la clé primaire, est-il un avantage spécifique à cette méthode par rapport à un substitut/artificiel clé? Je pense surtout en ce qui concerne la performance, la maintenance, l'administration, etc.?

EDIT 2

Il y a beaucoup de bonnes réponses ici, et il a été difficile de choisir le "meilleur", donc j'ai choisi celui que je pensais être utile, mais n'a pas reçu autant de voix, et voté les autres qui l'ont aidé à répondre à ma question.

Answer 1

J'suivre quelques règles:

1. Les clés primaires doit être aussi petite que nécessaire. Préférez un type numérique, parce que les types numériques sont stockés dans un beaucoup de format plus compact que les formats de caractères. C'est parce que la plupart des clés primaires sera la clé étrangère dans une autre table ainsi que utilisé dans de multiples indices. Le plus petit, le plus petit de l'index, le moins de pages dans le cache que vous allez utiliser.
2. Les clés primaires ne doit jamais changer. La mise à jour d'une clé primaire doit toujours être hors de question. C'est parce qu'il est le plus susceptible d'être utilisé dans de multiples indices et utilisé comme une clé étrangère. Mise à jour d'une clé primaire unique pourrait causer de l'effet de changements.
3. N'utilisez PAS votre problème de clé primaire" que votre modèle logique de la clé primaire. Par exemple, le numéro de passeport, numéro de sécurité sociale, ou de l'employé, le numéro de contrat comme ces "clé primaire" peut changer pour des situations du monde réel.

Sur de substitution vs clé naturelle, je me réfère aux règles ci-dessus. Si la clé naturelle est petit et ne changera jamais, il peut être utilisé comme clé primaire. Si la clé naturelle est grande ou susceptibles de changer, j'utilise des clés de substitution. Si il n'y a pas de clé primaire-je encore faire une clé de substitution, car l'expérience montre vous permettra de toujours ajouter des tables à votre schéma et souhaite que vous pourriez mettre une clé primaire.

Answer 2

Naturel versets artificiel touches est une sorte de religieux débat parmi la communauté des bases de données - voir cet article et les autres des liens vers elle. Je ne suis ni en faveur de toujours avoir artificielle clés, ni de ne jamais en avoir. Je voudrais décider au cas par cas, par exemple:

• États-unis: j'irais pour state_code ("TX" pour le Texas, etc.), plutôt que de state_id=1 pour le Texas
• Employés: j'avais l'habitude de créer un artificiel employee_id, car il est difficile de trouver quelque chose qui fonctionne. Le SSN ou l'équivalent peuvent travailler, mais il pourrait y avoir des questions comme l'un des nouveaux membres du personnel qui n'a pas fourni son SSN encore.
• De Salaire des employés de l'Histoire: (employee_id, date_debut). Je voudrais pas créer une artificielle employee_salary_history_id. Ce point serait-il servir (autres que les "folles de la cohérence")

Partout où artificielle clés sont utilisés, vous devez toujours déclarer les contraintes uniques sur les clefs naturelles. Par exemple, l'utilisation state_id si vous devez, mais vous feriez mieux de déclarer une contrainte unique sur state_code, sinon vous êtes sûr pour finalement se retrouver avec:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

Answer 3

- Je éviter d'utiliser des clés naturelles pour une simple raison, l'erreur humaine. Bien que les identifiants uniques sont souvent disponibles (SSN, VIN, Numéro de Compte, etc.), ils ont besoin d'un humain pour entrer correctement. Si vous utilisez SSNs comme clé primaire, quelqu'un qui transpose un couple de chiffres lors de la saisie de données, et l'erreur n'est pas découvert tout de suite, alors vous êtes confrontés à l'évolution de votre clé primaire.

Mes clés primaires sont tous manipulés par le programme de base de données en arrière-plan et l'utilisateur n'est jamais au courant d'entre eux.

Answer 4

Juste un commentaire supplémentaire sur quelque chose qui est souvent négligé. Parfois pas à l'aide d'une clé de substitution a des avantages dans les tables enfants. Disons que nous avons une conception qui vous permet d'exécuter plusieurs entreprises au sein d'une base de données (c'est peut-être une solution hébergée, ou quoi que ce soit).

Disons que nous avons ces tables et des colonnes:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

Dans le cas où ce dernier peu ne fait pas de sens, Invoice.CompanyId fait partie de deux clés étrangères l'une à l' CostCentre la table et un autre à la CostElement table. La clé primaire est (InvoiceId, CompanyId).

Dans ce modèle, il n'est pas possible de vis et de faire référence à un CostElement d'une compagnie et un CostCentre à partir d'une autre société. Si une clé de substitution a été utilisé sur le CostElement et CostCentre tables, il serait.

Le moins de chances de le visser en place, mieux c'est.

Answer 5

Theres aucun problème en faisant votre clé primaire à partir de divers domaines, c'est une Clé Naturelle.

Vous pouvez utiliser une colonne d'Identité (associé à un index unique sur le candidat champs) pour faire une Clé de Substitution.

C'est un vieux débat. Je préfère les clés de substitution dans la plupart des situations.

Mais theres aucune excuse pour le manque d'une touche.

RE: MODIFIER

Oui, il ya beaucoup de controverse à ce sujet :D

Je ne vois pas d'avantage évident sur les clefs naturelles, outre le fait qu'ils sont le choix naturel. Vous pensez toujours à en Nom de, SocialNumber - ou quelque chose comme ça - au lieu de idPerson.

Les clés de substitution sont la réponse à certains des problèmes que les touches (la propagation des modifications par exemple).

Que vous vous habituez à des mères porteuses, il semble plus propre, et facile à gérer.

Mais à la fin, vous trouvez que c'est juste une question de goût ou l'état d'esprit -. Les gens "pensent mieux" avec les clefs naturelles, et d'autres pas.