Pourquoi utiliser un int comme clé primaire d'une table de recherche?

Je veux savoir pourquoi je devrais utiliser un int comme clé primaire d'une table de recherche au lieu d'utiliser simplement la valeur de recherche comme clé primaire (qui dans la plupart des cas serait une chaîne).

Je comprends que l'utilisation d'un nvarchar (50) plutôt que d'un int utiliserait beaucoup plus d'espace s'il est lié à une table avec de nombreux enregistrements.

D'un autre côté, l'utilisation directe de la valeur de recherche nous éviterait essentiellement de faire une jointure. Je peux imaginer que ce serait une grande économie si la jointure est toujours requise (nous travaillons sur une application Web, donc cela compte un peu).

Quels sont les avantages de l'utilisation d'une clé primaire int (spécifiquement pour une table de recherche) autre que d'être "la chose standard à faire"?

La réponse à votre question est logique et non physique - la valeur que vous recherchez peut changer pour des raisons commerciales. Par exemple, si vous indexez vos clients par adresse e-mail, que se passe-t-il lorsqu'une adresse e-mail change? Évidemment, cela ne s'appliquera pas à toutes vos tables de recherche, mais les avantages de le faire de la même manière dans l'ensemble de l'application sont que cela rend votre code plus simple. Si tout est entier → relations entières en interne, vous êtes couvert.

Lisez simplement votre commentaire à Sandy - dans ce cas, ce que vous voulez vraiment, c'est une contrainte de vérification , pas une clé étrangère / table de recherche, par exemple:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

Exécutez ceci et vous obtenez:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

Il s'agit d'une méthode efficace et performante, mais l'inconvénient est bien sûr que l'ajout d'une nouvelle saveur signifie un changement de code. Je déconseille de le faire dans l'application - car alors vous devez le faire dans chaque application qui se connecte à cette base de données, c'est la conception la plus propre possible car il n'y a qu'un seul chemin de code pour faire la validation.

"Utiliser la valeur de recherche directement" - son peu contradictoire avec le but réel de la table de recherche. Pourquoi gardez-vous une telle table? Si ce n'est pas une recherche.
Peut-être ai-je mal compris votre question. Voici une définition de table de correspondance de msdn

Une table de recherche est utilisée pour afficher les informations d'une table en fonction de la valeur d'un champ de clé étrangère dans une autre table. Par exemple, considérons un tableau des commandes dans une base de données des ventes. Chaque enregistrement de la table Commandes comprend un identifiant client indiquant quel client a passé la commande. Le CustomerID est une clé étrangère pointant vers un enregistrement client dans la table Customers. Lorsque vous présentez une liste de commandes (dans le tableau Commandes), vous souhaiterez peut-être afficher le nom réel du client, par opposition à l'ID client. Étant donné que le nom du client se trouve dans la table des clients et que vous présentez des données de la table des commandes, vous devez créer une table de recherche, qui prend la valeur CustomerID dans l'enregistrement Orders et utilise cette valeur pour parcourir la relation et renvoyer plus lisible, nom du client.

Pouvez-vous expliquer le but de votre table de recherche? est-il utilisé pour stocker des données statiques comme les suivantes et ces enregistrements ne sont pas une entrée d'autres enregistrements de tables?

Table de saveurs

Orange  
Pista  
Mango

Si ci-dessus est votre situation, je voudrais recommander de ne pas utiliser la table de recherche; probablement coder en dur ces valeurs de liste dans votre application Web. De cette façon, vous pouvez éviter les requêtes de base de données inutiles.

Puisque vous avez qualifié votre question de «spécifiquement pour une table de recherche», la réponse est probablement simplifiée en «économise de l'espace».

Je pense que si vous supprimez ce qualificatif, votre question devient "Pourquoi utiliser des clés de substitution par rapport aux clés naturelles?" J'ai écrit ce qui suit à l'appui des clés de substitution:

"La migration d'une valeur entière au lieu d'une clé composée plus large présente de nombreux avantages. Elle offre une bonne cohérence à travers le modèle physique, économise en général plus d'espace qu'il en coûte et réduit les E / S par rapport à la migration de clés composées, en particulier dans un environnement bien- modèle normalisé. De plus, ils simplifient la compréhension d'un modèle et des jointures de requêtes. "

C'est en grande partie pourquoi il est "devenu la chose standard à faire". Le sous-produit malheureux est que les gens jettent une clé de substitution et ne pensent pas ce que sont les clés candidates ... Mais maintenant, nous sortons de votre question :)

L'une des raisons pour lesquelles j'utilise toujours est que si quelqu'un a mal orthographié une valeur dans la table de recherche, par exemple Oraneg au lieu d'Orange, il est très facile de modifier la valeur dans la table de recherche.

La table de recherche avec une clé primaire numérique ne nécessite que la valeur à modifier dans la table de recherche.

La table de recherche utilisant les valeurs comme clé primaire devra être modifiée dans la table de recherche et dans chaque enregistrement de la table principale où elle a été utilisée.

Lorsque vous définissez l'ID, vous pouvez également garantir l'unicité. Mais lorsque vous prenez, par exemple le courrier électronique, comme identifiant unique, vous déplacez la responsabilité de l'unicité vers un 3ème côté non fiable.