Clé primaire SQL: entier vs varchar

Question

L'équipe avec laquelle je travaille a décidé de créer une table avec une clé primaire varchar. Cette table est référencée par une autre table sur cette clé primaire.

J'ai l'habitude de créer une clé primaire entière, en suivant ce que j'ai appris à l'université. J'ai lu qu'il y avait une amélioration des performances en utilisant la clé primaire entière.

Le problème est que je ne connais aucune autre raison de créer une clé primaire entière. Avez-vous des conseils?

Answer 1

La clé primaire est censée représenter l'identité de la ligne et ne doit pas changer avec le temps.

Je suppose que le varchar est une sorte de clé naturelle - comme le nom de l'entité, une adresse e-mail ou un numéro de série. Si vous utilisez une clé naturelle, il peut parfois arriver que la clé doive changer car par exemple:

• Les données ont été incorrectement saisies et doivent être corrigées.
• L'utilisateur change son nom ou son adresse e-mail.
• La direction décide soudainement que tous les numéros de référence client doivent être modifiés dans un autre format pour des raisons qui vous semblent complètement illogiques, mais ils insistent pour effectuer le changement même après avoir expliqué les problèmes que cela vous causera.
• Peut-être même qu'un pays ou un État décide de changer l'orthographe de son nom - très peu probable, mais pas impossible.

En utilisant une clé de substitution, vous évitez les problèmes dus au changement de clés primaires.

Answer 2

VARCHAR vs INT ne dit pas grand-chose. Ce qui importe, c'est le modèle d'accès.

En termes absolus, une clé plus large sera toujours pire qu'une clé étroite. Le type n'a absolument aucune importance, c'est la largeur qui compte. Cependant, comparé à INT, peu de types peuvent battre INT dans l'étroitesse, donc INT gagne généralement cet argument juste par le fait qu'il ne fait que 4 octets de large.

Mais ce qui vraiment est le choix de la clé clusterisée . Souvent confondus avec la clé primaire, les deux représentent des notions différentes et sont pas nécessaires pour se chevaucher. Voici une discussion plus détaillée Dois-je concevoir une table avec une clé primaire de varchar ou int? Le choix de la clé en cluster est à peu près la décision la plus importante dans la conception de table, et une application mécanique d'un INT identity(1,1) dessus peut être la plus grosse erreur que l'on puisse faire. Voici où se pose la question des schémas d'accès:

• quelles sont les interrogations les plus fréquentes sur la table?
  • quelles colonnes sont projetées?
  • quels prédicats sont appliqués?
  • quelles plages sont recherchées?
  • quelles jointures sont effectuées?
  • quelles agrégations se produisent?
• comment les données sont-elles insérées dans le tableau?
• comment les données sont-elles mises à jour dans le tableau?
• comment les anciennes données sont-elles purgées de la table, si jamais?
• combien d'index non cluster existe-t-il?
  • à quelle fréquence les colonnes incluses dans les index NC (clé ou feuille) sont-elles mises à jour?

Dans l'ensemble, il existe de nombreux modèles d'accès qui peuvent être ruinés à l'aide d'une clé en cluster INT IDENTITY. Donc, avant de sauter pour appliquer une solution de coupe-biscuits, peut-être qu'un peu d'analyse est nécessaire ...

Quelques directives plus générales:

• Directives de conception d'index clusterisé
• Bases de la conception d'index
• Directives de conception d'index unique

Vous voyez qu'il n'y a pas de directives de conception de clé primaire, car la clé primaire n'est pas un problème de conception de stockage mais un problème de modélisation et est entièrement pilotée par domaine.

Answer 3

j'ai été un peu déçu parce que j'ai l'habitude de créer une clé primaire entière (suivant ce que certains professeurs m'ont dit à l'université). J'ai lu beaucoup de documentation sur l'augmentation des performances à l'aide d'une clé primaire entière.

Il y a un terme pour cela: biais de confirmation :

"également appelé biais de confirmation ou biais myside) est une tendance des gens à privilégier les informations qui confirment leurs idées préconçues ou hypothèses, qu'elles soient vraies ou non. Cela se traduit par la collecte sélective de nouvelles preuves, l'interprétation des preuves de manière biaisée ou le rappel sélectif informations de la mémoire. "

Bien sûr, votre première réaction sera de dire: "Mais ce n'est pas vrai!" Ouais, tu dirais que 'parce que tu es partiale;) [la langue fermement enfoncée dans la joue]

Voici un exemple classique: disons que votre professeur de zoologie vous a dit que tous les cygnes sont blancs et, bien sûr, tous les cygnes que vous et vos amis avez rencontrés sont blancs. Maintenant, disons que plus tard dans la vie, un collègue a exprimé l'opinion qu'il existe peut-être une créature comme un cygne noir. Quoi?! Ce n'est pas ce qu'on vous a appris. Votre monde est secoué! Vous sortez immédiatement et menez une enquête sur les cygnes et vous comptez 1 000 cygnes blancs et aucun cygne noir. Preuve! Si vous aviez trouvé 10 000 cygnes blancs, l'hypothèse "Tous les cygnes sont blancs" serait dix fois plus vraie, non?

Une approche différente serait d'oublier les cygnes blancs pour le moment et d'essayer de chercher un cygne noir. Peut-être prendre des vacances au bord de la mer sous le soleil Dawlish ?

Je ne veux vraiment pas paraître irrespectueux; vous admettez avoir lu beaucoup de choses sur ce qu'on vous a dit et cela mérite en effet mon respect. Voici donc un défi: essayez de trouver des cas où l'ajout d'une colonne entière à une table n'est pas nécessaire.

Voici quelques astuces et spoilers: des tables qui ne sont pas référencées par d'autres tables; tables de recherche à colonne unique "toutes les clés"; 'petites' tables peu sollicitées :)

Voici quelques autres sujets connexes que vous aimeriez étudier:

Le mot "primaire" dans "clé primaire" a-t-il beaucoup de sens ou toutes les clés d'une table donnée sont-elles égales?

Quelles sont les qualités d'une "bonne" clé? (par exemple, les valeurs d'une clé doivent-elles être immuables ou une stabilité est-elle suffisamment bonne?)

Une colonne entière est-elle ajoutée à la table en tant que clé artificielle (perhpas car la clé naturelle disponible n'est pas suffisamment `` bonne '') ou en tant que clé de substitution (peut-être pour améliorer les performances d'une clé naturelle autrement `` bonne '')?

Lorsqu'une clé de substitution est ajoutée à un tableau pour des raisons de performances, est-ce pour un effet mesuré réel ou simplement pour un effet perçu (c'est-à-dire une optimisation prématurée)?

Les clés de substitution doivent-elles apparaître dans le modèle commercial logique ou sont-elles uniquement destinées à la mise en œuvre?

Est-ce une bonne idée de toujours faire quelque chose (par exemple, ajouter une colonne entière à une table) sans engager le cerveau à chaque fois? ;)

[Avertissement: je suis un défenseur clé naturel et évite les substituts. Pour moi, ils sont comme la dénormalisation: vous ne le faites que lorsque vous le devez, généralement pour un problème de performances (spécifique et démontrable), où la faute se situe ailleurs (version du produit SQL moche, défaut de conception logique qui ne peut pas être corrigé à ce moment, etc.) ). Les substituts ne doivent jamais apparaître dans le modèle commercial logique. J'ai parfois besoin d'un identifiant artificiel et je leur ai même exposé des modèles commerciaux logiques.]