Chaque table doit-elle avoir une clé primaire?


341

Je crée une table de base de données et je n'ai pas de clé primaire logique qui lui est affectée. Donc, je pense à le laisser sans clé primaire, mais je me sens un peu coupable. Devrais-je?

Chaque table doit-elle avoir une clé primaire?


5
Pourriez-vous donner plus de détails sur la table? Mais la réponse est probablement "oui".
Ryan Bair

7
Oui, chaque table doit avoir une clé primaire.
Syed Tayyab Ali,

Réponses:


314

Réponse courte: oui .

Longue réponse:

  • Vous avez besoin que votre table soit joignable sur quelque chose
  • Si vous souhaitez que votre table soit mise en cluster, vous avez besoin d'une sorte de clé primaire.
  • Si la conception de votre table n'a pas besoin d'une clé primaire, repensez votre conception: il vous manque très probablement quelque chose. Pourquoi conserver des enregistrements identiques?

Dans MySQL, le moteur de stockage InnoDB crée toujours une clé primaire si vous ne l'avez pas spécifiée explicitement, créant ainsi une colonne supplémentaire à laquelle vous n'avez pas accès.

Notez qu'une clé primaire peut être composite.

Si vous avez une table de liens plusieurs à plusieurs, vous créez la clé primaire sur tous les champs impliqués dans le lien. Ainsi, vous vous assurez que vous n'avez pas deux enregistrements ou plus décrivant un lien.

Outre les problèmes de cohérence logique, la plupart des moteurs SGBDR bénéficieront de l'inclusion de ces champs dans un index unique.

Et comme toute clé primaire implique la création d'un index unique, vous devez le déclarer et obtenir à la fois une cohérence logique et des performances.

Consultez cet article dans mon blog pour savoir pourquoi vous devez toujours créer un index unique sur des données uniques:

PS Il y a des cas très, très spéciaux où vous n'avez pas besoin d'une clé primaire.

La plupart du temps, ils incluent des tables de journaux qui n'ont pas d' index pour des raisons de performances.


ils ont toujours une clé primaire, la clé composite
kristof

2
@annakata: ils devraient avoir une clé primaire composite
Quassnoi

1
"Et puisque toute CLÉ PRIMAIRE implique la création d'un index UNIQUE" n'est pas vrai pour Oracle. On peut utiliser un index non unique pour appliquer une clé primaire. En fait, il est parfois REQUIS que les contraintes uniques et PK utilisent des index non uniques.
Stephanie Page

3
Juste un commentaire sur la question rhétorique "Pourquoi tenir des registres identiques?". Notez que l'ajout d'un PK ne garantit pas qu'il n'y a pas de duplication. Souvent, le PK n'est pas visible pour l'utilisateur, donc ce qui est important est dans les champs visibles, qui pourraient contenir des données en double. Selon votre conception, cela peut être souhaitable ou non.
Rossco

1
Les clés n'ont rien à voir avec la joignabilité. Et l'argument de clustering dépend du SGBD que vous utilisez et mélange les considérations logiques et physiques.
Jon Heggland

36

Il est toujours préférable d'avoir une clé primaire. De cette façon, il rencontre la première forme normale et vous permet de continuer le long du chemin de normalisation de la base de données .

Comme indiqué par d'autres, il existe certaines raisons de ne pas avoir de clé primaire, mais la plupart ne seront pas endommagées s'il existe une clé primaire


5
@PaulSuart Les données ne doivent pas toujours être dans leurs formes normales. En fait, lorsque les données deviennent volumineuses, elles ne devraient pas être conservées sous leur forme normale, sinon l'accès aux données serait horriblement lent pour les requêtes effectuant des jointures de table, etc. Les formulaires normaux sont une «idéalisation» et pratiquement possibles uniquement lorsque les données ne devraient pas croître énorme.
Pacerier

13

Presque chaque fois que j'ai créé une table sans clé primaire, pensant que je n'en aurais pas besoin, j'ai fini par revenir en arrière et en ajouter une. Je crée maintenant même mes tables de jointure avec un champ d'identité généré automatiquement que j'utilise comme clé primaire.


13
Une table de jointure EST une clé primaire - une clé composite, composée des PK des deux enregistrements joints. Par exemple CREATE TABLE PersonOrder (PersonId int, OrderId int, PRIMARY KEY (PersonId, OrderId)).
Keith Williams

3
Oui, mais que se passe-t-il si la table des liens a également un troisième attribut, disons "OrderDate". Souhaitez-vous ajouter cela à la clé composite également? À mon humble avis non - car il est réductible et ne sert pas le caractère non réductible qu'une clé primaire devrait avoir.
stevek

13

À l'exception de quelques cas très rares (peut-être une table de relations plusieurs-à-plusieurs ou une table que vous utilisez temporairement pour charger en masse d'énormes quantités de données), j'irais avec le dicton:

S'il n'a pas de clé primaire, ce n'est pas une table!

Marc


10
À strictement parler, cette phrase est erronée. Les tableaux peuvent être des «tableaux d'affichage» créés par votre langage de requête. Un SGBDR est composé de relations et non de tables. Cette phrase devrait dire: "S'il n'a pas de clé primaire, ce n'est pas une relation!".
stevek

Ou peut-être, "s'il n'y a pas de clé candidate, ce n'est pas une table relationnelle". Mais voyez les cas très rares où il est acceptable d'avoir une table qui ne représente pas une relation.
Walter Mitty

Pourquoi une table plusieurs-à-plusieurs n'aurait-elle pas de clé primaire? Vous pouvez créer une clé primaire distincte, puis créer un index unique pour le substitut des clés étrangères. Je pense qu'il vaut mieux avoir une clé primaire sur chaque table. Même sur une table de chargement en bloc, vous souhaiterez peut-être identifier séparément une clé primaire qui n'inclut pas les données importées car cela peut vous aider à identifier les enregistrements en double dans un processus ETL. Il me semble que chaque table devrait toujours avoir une clé primaire, même si c'est un peu plus de stockage. Une table créée par une vue est un sous-ensemble d'une table et non une table elle-même.
John Ernest

1
Dans une table de relations plusieurs à plusieurs, vous pouvez créer une clé primaire composite composée des deux identifiants des relations.
Jaap

8

Ajoutez-le, vous serez désolé plus tard si vous ne l'avez pas fait (sélection, suppression. Liaison, etc.)


8

Aurez-vous jamais besoin de joindre cette table à d'autres tables? Avez-vous besoin d'un moyen d'identifier de manière unique un enregistrement? Si la réponse est oui, vous avez besoin d'une clé primaire. Supposons que vos données ressemblent à une table client qui contient les noms des personnes qui sont des clients. Il peut ne pas y avoir de clé naturelle car vous avez besoin des adresses, des e-mails, des numéros de téléphone, etc. pour déterminer si cette Sally Smith est différente de celle de Sally Smith et vous stockerez ces informations dans des tableaux connexes car la personne peut avoir plusieurs téléphones, adresses , courriels, etc. Supposons que Sally Smith épouse John Jones et devienne Sally Jones. Si vous n'avez pas de clé artificielle sur la table, lorsque vous mettez à jour le nom, vous venez de changer 7 Sally Smiths en Sally Jones même si un seul d'entre eux s'est marié et a changé son nom.

Vous dites que vous n'avez pas de clé naturelle, donc vous n'avez pas non plus de combinaisons de champs à rendre uniques, ce qui rend la clé artificielle critique.

J'ai trouvé à chaque fois que je n'ai pas de clé naturelle, une clé artificielle est un must absolu pour maintenir l'intégrité des données. Si vous avez une clé naturelle, vous pouvez l'utiliser à la place comme champ clé. Mais personnellement, à moins que la clé naturelle ne soit un champ, je préfère toujours une clé artificielle et un index unique sur la clé naturelle. Vous le regretterez plus tard si vous n'en mettez pas.


6

C'est une bonne pratique d'avoir un PK sur chaque table, mais ce n'est pas un MUST. Très probablement, vous aurez besoin d'un index unique et / ou d'un index cluster (qui est PK ou non) en fonction de vos besoins.

Consultez les sections Clés principales et Index clusterisés sur la documentation en ligne (pour SQL Server)

"Les contraintes PRIMARY KEY identifient la colonne ou l'ensemble de colonnes qui ont des valeurs qui identifient de manière unique une ligne dans une table. Deux lignes d'une table ne peuvent pas avoir la même valeur de clé primaire. Vous ne pouvez pas entrer NULL pour une colonne d'une clé primaire. Nous nous vous recommandons d'utiliser une petite colonne entière comme clé primaire. Chaque table doit avoir une clé primaire. Une colonne ou une combinaison de colonnes qualifiées comme valeur de clé primaire est appelée clé candidate. "

Mais vérifiez également ceci: http://www.aisintl.com/case/primary_and_foreign_key.html



4
cette page est assez stupide. Tout d'abord, une clé primaire est nécessaire pour des raisons de performances. En lisant sa page, j'apprends que l'ajout d'un identifiant à une table de livre est inutile car le texte du livre est unique; Évidemment, le gars n'a jamais travaillé avec des bases de données, mais il a aussi des problèmes pour comprendre ce qu'il critique. Page écrite que 1) une valeur PK fait référence à une ligne 2) vous pouvez joindre 2 tables par n'importe quel ensemble de colonnes. Il n'y a pas de contradiction. Il est étonnant qu'un auteur d'article académique ne comprenne pas les bases de la théorie relationnelle.
Federico Razzoli du

1
"Tout d'abord, une clé primaire est nécessaire pour des raisons de performances" ceci est incorrect, PK n'affecte pas directement les performances. Ne pas avoir de PK peut entraîner de nombreux problèmes (identification d'une ligne, jonction, etc.) mais les performances n'en font pas partie. Lorsque vous créez PK sur une table SQL Server crée un index cluster unique, cet index affecte les performances et non le PK lui-même. À titre d'exemple réel, ma table a une colonne d'index en cluster sur la date et un PK sur un champ GUID, car mes lignes doivent être physiquement ordonnées sur la colonne de date dans la table car toutes les requêtes ont une plage de dates (dans mon cas).
endo64

Cet index cluster est une version de la clé primaire, créée par SQL Server et plusieurs autres SGBD. Etes-vous sûr que c'est une bonne idée de l'utiliser? Par exemple, dans MySQL, ce n'est pas pour plusieurs raisons non documentées.
Federico Razzoli

1
Gardez à l'esprit que GUID n'est pas un type optimal pour les PK, dans InnoDB. Tous les index contiennent une référence au PK donc, plus le PK est grand, plus tous les autres index seront gros.
Federico Razzoli

6

En désaccord avec la réponse suggérée. La réponse courte est: NON .

Le but de la clé primaire est d'identifier de manière unique une ligne sur la table afin de former une relation avec une autre table. Traditionnellement, une valeur entière auto-incrémentée est utilisée à cet effet, mais il existe des variantes.

Il existe cependant des cas, par exemple l'enregistrement de données de séries chronologiques, où l'existence d'une telle clé n'est tout simplement pas nécessaire et prend simplement de la mémoire. Rendre une rangée unique n'est tout simplement pas nécessaire!

Un petit exemple: Tableau A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

Aucune clé primaire nécessaire.

Tableau B: utilisateur

Columns: Id, FirstName, LastName etc. 

Clé primaire (Id) nécessaire pour être utilisée comme "clé étrangère" dans la table LogData.


3

Je sais que pour utiliser certaines fonctionnalités de la grille dans .NET, vous avez besoin d'une clé primaire pour que la grille sache quelle ligne doit être mise à jour / supprimée. La pratique générale devrait être d'avoir une clé primaire ou un cluster de clés primaires. Personnellement, je préfère le premier.


3

Pour le rendre à l'épreuve du temps, vous devriez vraiment. Si vous voulez le reproduire, vous en aurez besoin. Si vous voulez le joindre à une autre table, votre vie (et celle des pauvres fous qui doivent la maintenir l'année prochaine) sera tellement plus facile.


Je ne suis pas encore convaincu que ce soit nécessaire, mais "faites-le parce que sinon quelqu'un devra faire face aux conséquences plus tard" est suffisant pour me faire pécher par excès. Je peux toujours laisser tomber la colonne plus tard si cela semble utile d'essayer de la réduire ...
ArtOfWarfare

3

Je suis dans le rôle de maintenir l'application créée par l'équipe de développement offshore. Maintenant, je rencontre toutes sortes de problèmes dans l'application car le schéma de base de données d'origine ne contenait pas de CLÉS PRIMAIRES sur certaines tables. Alors ne laissez pas les autres souffrir à cause de votre mauvaise conception. C'est toujours une bonne idée d'avoir des clés primaires sur les tables.


2

J'ai toujours une clé primaire, même si au début je n'ai pas encore de but en tête. Il y a eu quelques fois où j'ai finalement eu besoin d'un PK dans une table qui n'en a pas et c'est toujours plus difficile de le mettre plus tard. Je pense qu'il y a plus d'un avantage à toujours en inclure un.


1

Bref, non. Cependant, vous devez garder à l'esprit que certaines opérations CRUD d'accès client l'exigent. Pour l'épreuvage futur, j'ai tendance à toujours utiliser des clés primaires.


1

Si vous utilisez Hibernate, il n'est pas possible de créer une entité sans clé primaire. Ces problèmes peuvent créer un problème si vous travaillez avec une base de données existante qui a été créée avec des scripts sql / ddl simples et qu'aucune clé primaire n'a été ajoutée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.