- Que sont les clés ?
- Clés simples
- Clés concaténées ou composées
- Clés primaires
- Numération et incrémentation automatique
- Une table peut-elle contenir plusieurs clés primaires ?
Alors que de nombreux développeurs et administrateurs de bases de données peuvent travailler avec des primary keys tous les jours, c'est un sujet fascinant de se demander, "Qu'est-ce exactement est une primary key et peut (ou doit) une table de base de données contenir plusieurs primary keys simultanément ?"
Ci-dessous, nous examinerons ces questions plus en détail et essaierons de parvenir à un consensus raisonnable et généralement convenu au sein de la communauté du développement.
Que sont les clés ?
Pour comprendre ce qu'est une primary key est dans une table de base de données, nous devons d'abord comprendre un peu les non-primary keys . Une key dans une table est simplement un attribut qui est utilisé pour identifier et accéder à ces informations. Une table peut avoir et aura souvent plusieurs clés, comme dans la table Users les deux email et username pourraient être considérés comme des clés.
Selon le développeur ou l'administrateur à qui vous parlez, vous pouvez entendre parler d'une variété de types de clés et de leurs définitions, nous allons donc couvrir quelques exemples différents ci-dessous et une définition de base de chacun.
Clés simples
Une simple key est juste une clé utilisant un seul attribut dans la table. Sauf si nous imposons plus de restrictions sur la clé ou la table, alors le username l'attribut dans l'exemple ci-dessus est une simple key .
Clés concaténées ou composées
Un peu plus loin que les simple keys sont concatenated ou compound clés. Comme son nom l'indique, une concatenated key est une réunion de plusieurs single keys . Par exemple, le système peut combiner automatiquement le last_name et year_of_birth single keys dans une concatenated key , comme ceci :smith1980 .
Clés primaires
Une [primary key](https://en.wikipedia.org/wiki/Unique_key) est une clé qui a été choisie comme principale (ou primaire ) attribut représentatif pour cette ligne de données. La primary key est unique et cet attribut est ensuite utilisé dans toute la base de données et est accessible et transmis à d'autres tables en tant qu'attribut représentatif des données en question.
En pratique, la primary key l'attribut est également marqué comme NOT NULL dans la plupart des bases de données, ce qui signifie que cet attribut doit toujours contenir une valeur pour que l'enregistrement soit inséré dans la table.
Par exemple, soit le email ou username simple keys pourrait se voir attribuer la désignation de la primary key , mais il est généralement préférable de définir la primary key à un attribut qui n'est pas (ou ne peut pas) être modifié par la logique métier ou même par l'individu. Par exemple, imaginez un User obtient une nouvelle adresse e-mail, ce qui provoque alors toutes les anciennes primary key les associations faites à l'aide de l'ancienne adresse e-mail deviennent invalides lors de l'utilisation de la nouvelle adresse e-mail.
Pour cette raison (entre autres), la plupart des primary keys utilisez un nombre ou une chaîne unique, comme un [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) .
Numération et auto-incrémentation
Il convient également de noter brièvement que de nombreux systèmes de base de données sont configurés de telle manière que chaque table a une primary key qui est à la fois numérique et auto-incrémenté. Cela signifie simplement que le moteur de base de données lui-même attribue automatiquement à chaque nouvel enregistrement de cette table une primary key unique valeur qui est incrémentiellement plus grande que toutes les valeurs précédentes. Cependant, la plupart des développeurs conviennent que cette pratique est obsolète et expose des failles de sécurité inutiles pour le système lorsqu'elle est utilisée pour certains tableaux qui représentent certaines données.
Par exemple, imaginez tous les User les enregistrements se voient attribuer une primary key auto-incrémentée valeur, connue sous le nom de id attribut. Si une personne malveillante découvre que l'id l'attribut d'un utilisateur donné (par exemple John Smith) est la valeur 1500 , cela expose déjà un peu d'informations. Tout d'abord, cela indique qu'il y a probablement au moins 1499 autres utilisateurs dans le système, ou qu'ils l'ont été à un moment donné. Cela signifie également que si la page utilisateur de John Smith est accessible via une URL ou un appel d'API contenant cet id valeur de 1500 , il y a de fortes chances de simplement changer la valeur en un autre nombre, tel que 1499 ou 1501 , exposera la page d'un autre utilisateur qui peut ne pas vouloir que sa page soit consultée par ce visiteur. De cette manière, les enregistrements peuvent être interrogés simplement en devinant l'id valeurs sur une échelle de masse.
Ce sont évidemment des exemples très simples, mais pour ces raisons, la plupart des bases de données modernes utiliseront une primary key aléatoire et unique valeur d'attribut telle qu'un UUID lorsque vous travaillez avec des données sensibles.
Une table peut-elle contenir plusieurs clés primaires ?
La réponse courte est non , une table ne peut pas contenir plusieurs primary keys , car cela va à l'encontre des principes fondamentaux de la conception de bases de données relationnelles (voir :[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) et [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ).
C'est c'est possible pour une table d'avoir plusieurs candidate keys , qui se comportent effectivement comme une primary key en ce qu' une candidate key est unique, NOT NULL , et est une représentation singulière de cet enregistrement de table.
Cependant, lorsqu'il s'agit de sélectionner lequel un l'attribut sera assigné comme primary key pour le tableau, le choix vient de la liste de toutes les candidate keys potentielles (d'où le nom, ils sont candidats pour devenir une primary key ). Au final, une seule candidate key est sélectionné comme meilleur attribut représentatif pour cet enregistrement, à utiliser dans ce tableau comme primary key et référencés ailleurs dans la base de données par d'autres tables via leurs foreign keys respectives .
