Comment aimez-vous vos clés primaires?

Question

Dans une assez vive discussion dans mon équipe, j'étais à penser que la plupart des gens comme clés primaires. Nous avons eu l'groupes suivants-

1. Int/ BigInt qui autoincrement sont assez bonnes clés primaires.
2. Il devrait y avoir au moins 3 colonnes qui composent la clé primaire.
3. Id, GUID et lisible par l'homme identificateurs de lignes tous doivent être traités différemment.

Quelle est la meilleure approche pour PKs? Il serait génial si vous pouviez justifier votre opinion. Est-il une meilleure méthode que ci-dessus?

EDIT: quelqu'un a un exemple simple/algorithme pour générer lisible par l'homme d'identifiants pour les lignes qui s'adapte bien?

Answer 1

Si vous allez faire de la synchronisation entre les bases de données avec de temps en temps des applications connectées, alors vous devriez être en utilisant le Guid pour vos clés primaires. C'est une sorte de douleur pour le débogage, donc, en dehors de ce cas, j'ai tendance à coller à ints que autoincrement.

Autoincrement ints par défaut, et non leur utilisation doit être justifiée.

Answer 2

Je ne vois pas une réponse qui souligne (ce que je considère comme) vraiment fondamentaux du point - à savoir, qu'une clé primaire est ce qui garantit que vous ne serez pas obtenir deux entrées dans la table pour la même entité du monde réel (comme modélisées dans la base de données). Cette observation permet d'établir quels sont les bons et quels sont les mauvais choix pour la clé primaire.

Par exemple, dans une table de (US) état des noms et des codes, soit le nom ou le code pourrait être la clé primaire - elles constituent deux candidats différents clés, et l'un d'eux (normalement le plus court - le code) est choisi comme clé primaire. Dans la théorie de la fonctionnelle de dépendances (et rejoignez dépendances - 1FN par 5NF - c'est le candidat clés qui sont essentiels plutôt que d'une clé primaire.

Pour un contre-exemple, des noms généralement de faire un mauvais choix pour la clé primaire. Il y a beaucoup de gens qui vont par le nom de "John Smith" ou d'autres noms; même en prenant des prénoms en compte (rappelez-vous: le monde n'a pas un pour exemple, je n'ai pas), il existe de nombreuses possibilités pour la duplication. Par conséquent, les gens n'utilisent pas les noms que les clés primaires. Ils inventent des clés artificielles telles que le Numéro de Sécurité Sociale (SSN) ou Numéro d'Employé et de les utiliser pour désigner l'individu.

Un idéal de clé primaire est court, unique, mémorable, et naturel. De ces caractéristiques, l'unicité est obligatoire; les autres ont pour flex, compte tenu des contraintes de données du monde réel.

Quand il s'agit de la détermination de la clé primaire d'une table, par conséquent, vous devez regarder ce que le tableau représente. Quel ensemble ou des ensembles de valeurs de colonne dans le tableau identifie de manière unique chaque ligne de la table? Ce sont les candidats les touches. Maintenant, si chaque candidat se compose de 4 ou 5 colonnes, vous pouvez décider que ceux-ci sont trop maladroit pour faire une bonne clé primaire (principalement pour des raisons de brièveté). Dans ces circonstances, vous pouvez introduire une clé de substitution - un générés artificiellement le nombre. Très souvent (mais pas toujours) un simple entier de 32 bits est suffisant pour la clé de substitution. Vous puis désigner cette clé de substitution en tant que clé primaire.

Cependant, vous devez toujours vous assurer que l'autre candidat clés (pour la clé de substitution est une clé candidate de trop, ainsi que la choisi clé primaire) sont tous maintenus comme identifiant unique, normalement en plaçant une contrainte unique sur ces ensembles de colonnes.

Parfois, les gens trouvent qu'il est difficile d'identifier ce qui fait une ligne unique, mais il devrait être quelque chose à faire, parce que tout simplement la répétition d'un morceau de l'information n'en est pas plus vrai. Et si vous n'êtes pas prudent et faire obtenir deux (ou plus) lignes visant à stocker la même information, et ensuite, vous devez mettre à jour les informations, il y a un danger (surtout si vous utilisez des curseurs) qui vous permettra de mettre à jour seulement une ligne plutôt que chaque ligne, de sorte que les lignes sont hors de la synchronie et nul ne sait la ligne qui contient les informations correctes.

C'est assez dur de ligne de vue, à certains égards.

J'ai pas de problème particulier avec l'utilisation d'un GUID quand ils sont nécessaires, mais ils ont tendance à être grand (comme dans les 16 à 64 octets), et ils sont utilisés trop souvent. Très souvent une très bonne valeur de 4 octets suffirait. À l'aide d'un GUID où une valeur de 4 octets suffirait gaspille de l'espace disque, et ralentit même indexée accès aux données depuis il y a moins de valeurs par la page d'index, de sorte que l'indice sera plus profonde et plus de pages à lire pour obtenir l'information.

Answer 3

Ce n'est qu'une question de religion, car les gens cherchent un droit universel de réponse. Le fait que les deux de votre équipe et de ce fil montre tellement désaccord doit être un indice qu'il y a de bonnes raisons d'utiliser toutes les solutions que vous décrivez, dans des circonstances différentes.

• Les clés de substitution sont utiles lorsque aucun autre attribut ou un ensemble d'attributs dans le tableau est adapté pour identifier les lignes de façon unique.
• Les clefs naturelles sont à privilégier, lorsque cela est possible, pour rendre le tableau plus lisible par l'homme. Naturel touches permettent également la clé étrangère dans une table dépendante de contenir une valeur réelle au lieu d'une substitution d'identité. E. g. lorsque vous avez besoin de stocker state (CALIFORNIE, TEXAS, new york) vous pourriez aussi bien utiliser un char(2) naturel clé au lieu d'un int.
• Utilisation de composés de clés primaires, le cas échéant. N'ajoutez pas un "id" clé de substitution inutilement lors d'une clé composée existe (c'est particulièrement vrai dans plusieurs-à-plusieurs tables). Un mandat pour une période de trois clé de colonne de chaque table est un non-sens absolu.
• Les guid sont une solution lorsque vous avez besoin afin de préserver l'unicité sur plusieurs sites. Ils sont également à portée de main si vous avez besoin de valeurs dans la clé primaire unique, mais pas commandés ou consécutifs.
• INT vs BIGINT: il n'est pas commun qu'un tableau nécessite une version 64 bits de gamme pour les clés primaires, mais avec l'augmentation de la disponibilité du matériel 64 bits, il ne devrait pas être un fardeau, et donne plus d'assurance que vous ne débordera pas. INT est bien sûr plus petit, donc si l'espace est à une prime, il peut donner un léger avantage.

Answer 4

J'aime Le Programmeur de Base de données blog comme une source pour ce genre d'info.

3 colonnes de clé primaire? Je dirais que les colonnes devraient avoir des contraintes uniques comme les règles de gestion de la demande, mais je préfère toujours avoir une clé de substitution. Composé de touches de dire la logique d'entreprise entre dans la clé. Si la logique des changements, votre schéma est vissé.

Answer 5

J'aime le mien unique.