Quand utiliser une clé primaire auto-incrémentée et quand ne pas l'utiliser?
J'essaie de déterminer les "meilleures pratiques" pour décider d'ajouter ou non un entier auto-incrémenté en tant que clé primaire à une table.
Disons que j'ai un tableau contenant des données sur les éléments chimiques. Le numéro atomique de chaque élément est unique et ne changera jamais. Ainsi, plutôt que d’utiliser un entier auto-incrémenté pour chaque colonne, il serait probablement plus logique d’utiliser simplement le numéro atomique, n’est-ce pas?
La même chose serait-elle vraie si j'avais une table de livres? Devrais-je utiliser l'ISBN ou un entier auto-incrémenté pour la clé primaire? Ou un tableau des employés contenant le numéro de sécurité sociale de chaque personne?
Il existe de nombreuses questions déjà traitées sur le dépassement de capacité qui peuvent vous aider à résoudre vos questions. Voir ici , ici , ici et ici .
Le terme que vous devriez rechercher: clés de substitution .
J'espère que ça aide.
C'est une question très discutée, avec beaucoup d'émotion des deux côtés.
À mon humble avis, s'il existe une bonne clé naturelle utilisable, telle qu'un ISBN, je l'utilise. Je vais quand même le stocker dans la base de données. Oui, une clé naturelle est généralement plus grosse qu'une clé à incrémentation automatique entière, mais je pense que ce problème est surexploité. L'espace disque est bon marché aujourd'hui. Je m'inquiéterais davantage du temps de traitement. Si vous parliez d'un champ de texte de 80 octets en tant que clé primaire, je dirais non. Mais si vous envisagez d'utiliser un ISBN de 10 octets au lieu d'un grand entier de 8 octets, je ne peux pas imaginer que cela entraîne une pénalité de performances.
Parfois, les clés naturelles présentent un avantage en termes de performances. Supposons, par exemple, que je veuille savoir combien d'exemplaires d'un livre donné ont été vendus. Je me fiche de toutes les données de la fiche du livre. Si la clé primaire est ISBN, je pourrais simplement écrire "select count (*) from sale où isbn = '143573338X" ". Si j’utilisais une clé auto-incrémentée, je devrais faire une jointure pour rechercher l’isbn, et la requête devient plus complexe et plus lente, comme "select count (*) from book join sale using" (bookid) où isbn = '143573338X " ". (Et je peux vous assurer que, comme cet ISBN est spécifique à mon livre, le nombre d'enregistrements de vente est très faible, par conséquent, la jointure et la lecture d'un enregistrement supplémentaire représentent une différence importante en pourcentage!)
Un autre avantage des clés naturelles est que lorsque vous devez travailler sur la base de données et que vous examinez les enregistrements qui se réfèrent à cette table par clé, il est facile de voir à quel enregistrement ils font référence.
D'un autre côté, s'il n'y a pas de bonne clé naturelle évidente, n'essayez pas de bricoler une folle. J'ai vu des gens essayer de créer une clé naturelle en concaténant ensemble les 6 premières lettres du prénom du client, de son année de naissance et de son code postal, puis de prier pour que ce soit unique. Ce genre de sottise ne fait que créer des problèmes pour vous-même. Souvent, les gens finissent par prendre un numéro de séquence pour s'assurer que c'est unique de toute façon, et à ce moment-là, pourquoi s'embêter? Pourquoi ne pas simplement utiliser le numéro de séquence comme clé?
Vous avez l'idée ici.
L'incrémentation automatique doit être utilisée comme clé unique lorsqu'aucune clé unique n'existe déjà concernant les éléments que vous modélisez. Ainsi, pour les éléments, vous pouvez utiliser le numéro atomique ou Livres le numéro ISBN.
Mais si des personnes postent des messages sur un tableau d'affichage, ils ont besoin d'un identifiant unique, mais n'en contiennent pas naturellement. Nous attribuons donc le numéro suivant à partir d'une liste.
Il est judicieux d'utiliser des clés naturelles dans la mesure du possible. N'oubliez pas de définir le champ comme clé primaire et de vous assurer qu'il est indexé pour améliorer les performances.
Le principal problème que j'ai constaté avec l'approche de l'incrémentation automatique d'un nombre entier est lié à l'exportation de vos données à importer dans une autre instance de base de données, voire à une opération d'archivage et de restauration. Étant donné que l'entier n'a aucune relation avec les données qu'il référence, il n'existe aucun moyen de déterminer s'il existe des doublons lors de la restauration ou de l'ajout de données à une base de données existante. Si vous ne voulez pas de relation entre les données contenues dans la ligne et la PK, je voudrais simplement utiliser un guid. Pas très convivial à regarder, mais cela résout le problème ci-dessus.
En ce qui concerne l'utilisation de l'ISBN et du SSN, vous devez vraiment penser au nombre de lignes des autres tables qui vont les référencer à l'aide de clés étrangères, car ces identifiants prendront beaucoup plus de place qu'un entier, ce qui peut entraîner un gaspillage d'espace disque. peut-être pire pour rejoindre les performances.
J'essaie de déterminer les "meilleures pratiques" pour décider d'ajouter ou non un entier auto-incrémenté en tant que clé primaire à une table.
Utilisez-le comme identifiant unique avec un jeu de données dans lequel la clé PKey ne fait pas partie des données gérées par l'utilisateur.
Disons que j'ai un tableau contenant des données sur les éléments chimiques. Le numéro atomique de chaque élément est unique et ne changera jamais. Ainsi, plutôt que d’utiliser un entier auto-incrémenté pour chaque colonne, il serait probablement plus logique d’utiliser simplement le numéro atomique, n’est-ce pas?
Oui.
La même chose serait-elle vraie si j'avais une table de livres? Devrais-je utiliser l'ISBN ou un entier auto-incrémenté pour la clé primaire? Ou un tableau des employés contenant le numéro de sécurité sociale de chaque personne?
Les numéros ISBN/SS sont attribués par des tiers et, en raison de la taille de leur stockage, constitueraient un moyen extrêmement inefficace d'identifier de manière unique une ligne. N'oubliez pas que les PKeys sont utiles lorsque vous joignez des tables. Pourquoi utiliser un format de données volumineux tel qu'un ISBN, qui pourrait contenir de nombreux caractères textuels comme identifiant unique lorsqu'un format compact et compact comme Integer est disponible?
Vieux sujet que je connais, mais une autre chose à considérer est que, étant donné que la plupart des SGBDR placent des blocs sur le disque en utilisant le PK, utiliser un PK auto-incrémenté augmentera simplement massivement votre conflit. Cela ne pose peut-être pas un problème pour la base de données de votre bébé avec laquelle vous bricolez, mais croyez-moi, cela peut entraîner d’énormes problèmes de performances au plus grand bout de la ville.
Si vous devez utiliser un identifiant auto-incrémenté, envisagez de l’utiliser comme partie d’une PK. Attaquez-vous au bout pour maintenir l'unicité .....
En outre, il est préférable d’épuiser toutes les possibilités offertes par les PC naturelles avant de passer à une mère porteuse. Les gens sont généralement paresseux avec cela.