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 source
Réponses:
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:
Exécutez ceci et vous obtenez:
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.
la source
"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
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
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.
la source
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 :)
la source
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.
la source
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.
la source