Chaque table doit-elle avoir une clé primaire?

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?

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:

• Rendre un index UNIQUE

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.

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

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.

À 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

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

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.

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

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.

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.

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 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.

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.

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.

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.