Chaque table doit-elle avoir une clé primaire?
Je crée une table de base de données et aucune clé primaire logique ne lui est affectée. Donc, je pense le laisser sans clé primaire, mais je me sens un peu coupable à ce sujet. 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 de clé primaire, repensez-la: il est fort probable qu'il vous manque quelque chose. Pourquoi garder des enregistrements identiques?
Dans MySQL, le moteur de stockage InnoDB crée toujours une clé primaire si vous ne le spécifiez pas 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 ou plusieurs enregistrements décrivant un lien.
Outre les problèmes de cohérence logique, la plupart des moteurs de 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 la cohérence logique et les performances.
Consultez cet article dans mon blog pour savoir pourquoi vous devriez toujours créer un index unique sur des données uniques:
P.S. Il existe quelques très, très cas particuliers dans lesquels vous n'avez pas besoin de clé primaire.
Pour la plupart, ils incluent des tables de journalisation qui ne possèdent pas d'index pour des raisons de performances.
Il vaut toujours mieux avoir une clé primaire. De cette façon, il rencontre première forme normale et vous permet de continuer le long du chemin normalisation de la base de données .
Comme d'autres l'ont indiqué, il y a certaines raisons de ne pas avoir de clé primaire, mais la plupart ne seront pas endommagées s'il y a une clé primaire
À l'exception de quelques cas très rares (éventuellement une table de relations plusieurs-à-plusieurs ou une table que vous utilisez temporairement pour le chargement en vrac d'énormes quantités de données), j'adopterais le dicton suivant:
S'il n'a pas de clé primaire, ce n'est pas une table!
Marc
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.
Ajoutez-le simplement, vous serez désolé plus tard quand vous ne l'auriez pas fait (sélection, suppression. Liens, etc.)
Aurez-vous 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 de clients contenant les noms des clients. Il peut ne pas y avoir de clé naturelle car vous avez besoin des adresses, des courriels, 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 Internet, etc. , 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 remplacez 7 Sally Smiths par Sally Jones, même si une seule d'entre elles s'est mariée et a changé de nom. Et bien sûr dans ce cas sans clé artificielle, comment savoir quelle Sally Smith habite à Chicago et laquelle habite à LA?
Vous dites que vous n’avez pas de clé naturelle, donc vous n’avez aucune combinaison de champs à rendre unique non plus, cela rend la clé artificielle essentielle.
J'ai trouvé à chaque fois que je n'avais pas de clé naturelle, une clé artificielle est un impératif absolu pour préserver l'intégrité des données. Si vous avez une clé naturelle, vous pouvez plutôt l'utiliser comme champ de clé. Mais personnellement, sauf si la clé naturelle est 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 une obligation. Très probablement, vous aurez besoin d'un index unique et/ou d'un index en cluster (avec ou sans clé) en fonction de vos besoins.
Consultez les sections Clés principales et Index clusterisés dans la documentation en ligne (pour SQL Server).
" Les contraintes PRIMARY KEY identifient la colonne ou l'ensemble de colonnes dont les valeurs identifient de manière unique une ligne dans une table. Aucune ligne dans une table ne peut avoir la même valeur de clé primaire. Vous ne pouvez pas entrer NULL. Pour chaque colonne d'une clé primaire, 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 de valeur de clé primaire est appelée clé candidate. "
Mais vérifiez aussi ceci: http://www.aisintl.com/case/primary_and_foreign_key.html
Je sais que pour utiliser certaines fonctionnalités de gridview dans .NET, vous avez besoin d'une clé primaire afin de permettre à gridview de savoir quelle ligne doit être mise à jour/supprimée. La pratique générale devrait consister à avoir une clé primaire ou un cluster de clés primaires. Personnellement, je préfère l'ancien.
Pour le rendre futur, vous devriez vraiment. Si vous voulez le reproduire, vous en aurez besoin d'un. Si vous voulez vous joindre à une autre table, votre vie (et celle des pauvres imbéciles qui devront la maintenir l'année prochaine) sera tellement plus facile.
J'ai toujours une clé primaire, même si au début je n'ai pas encore de but en tête. À plusieurs reprises, j'ai finalement eu besoin d'une PC dans une table qui n'en avait pas et c'est toujours plus difficile de la mettre plus tard. Je pense qu'il y a plus d'un avantage à en inclure toujours un.
Si vous utilisez Hibernate, il est impossible de créer une entité sans clé primaire. Ce problème peut créer un problème si vous travaillez avec une base de données existante qui a été créée avec des scripts plain SQL/ddl et qu'aucune clé primaire n'a été ajoutée.
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 PRIMARY KEYS sur certaines tables. Alors s'il vous plaît ne laissez pas d'autres personnes souffrir à cause de votre mauvaise conception. C'est toujours une bonne idée d'avoir des clés primaires sur les tables.
En désaccord avec la réponse suggérée. La réponse courte est: NO.
L'objectif de la clé primaire est d'identifier de manière unique une ligne de la table afin de former une relation avec une autre table. Traditionnellement, une valeur entière auto-incrémentée est utilisée à cette fin, mais il existe des variantes.
Il existe cependant des cas, par exemple l’enregistrement de données chronologiques, dans lesquels l’existence d’une telle clé n’est tout simplement pas nécessaire et nécessite juste de la mémoire. Rendre une ligne unique est tout simplement… inutile.
Un petit exemple: Table A: LogData
Columns: DateAndTime, UserId, AttribA, AttribB, AttribC etc...
Aucune clé primaire nécessaire.
Tableau B: utilisateur
Columns: Id, FirstName, LastName etc.
La clé primaire (Id) est nécessaire pour pouvoir être utilisée comme "clé étrangère" de la table LogData.
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.