Je pense que le besoin est un mot très fort, et au sens strict, les tables n'ont probablement pas besoin de clés de substitution .
Cependant, si c'était ma base de données, j'ajouterais probablement des clés de substitution de toute façon. Je ne veux pas nécessairement que ma conception de base de données dépende d'un tas de tiers (IATA, ISO), quelle que soit la stabilité de leurs normes. Ou, je ne veux pas du tout dépendre d'une norme particulière (existe-t-il d'autres normes de code de devise? Je ne sais pas). Je modéliserais probablement mes tables avec des clés de substitution comme ceci:
+-------------------------+ +------------------------+
|Airport | |Country |
|-------------------------| |------------------------|
|airport_id int (PK)| |country_id int (PK) |
|iata_airport_code string | |iso_country_code string |
|icao_airport_code string | +------------------------+
|faa_identifier string |
|address string |
|name string |
+-------------------------+
+-------------------------+
|Currency |
|-------------------------|
|currency_id int (PK) |
|iso_currency_code string |
|name string |
+-------------------------+
En d'autres termes, à moins que ces codes standard de l'industrie ne soient intrinsèquement importants pour mon application, je ne les utiliserais pas comme PK de mes tables. Ce ne sont que des étiquettes. La plupart de mes autres tables auront probablement des clés de substitution de toute façon, et cette configuration ajouterait de la cohérence à mon modèle de données. Le coût de «l'ajout» des clés de substitution est minime.
Mise à jour basée sur certains des commentaires:
Sans connaître le contexte des exemples de tableaux, il est impossible de savoir à quel point des éléments tels que les codes d'aéroport IATA sont importants pour l'application utilisant la base de données. De toute évidence, si les codes IATA sont d'une importance centrale et utilisés de manière omniprésente dans l'application, il pourrait être la bonne décision, après une analyse appropriée, d'utiliser les codes comme PK de la table.
Cependant, si la table est juste une table de recherche utilisée dans quelques coins de l'application, l'importance relative des codes IATA peut ne pas justifier une place aussi importante dans l'infrastructure de la base de données. Bien sûr, vous devrez peut-être faire une jointure supplémentaire dans quelques requêtes ici et là, mais cet effort pourrait être trivial par rapport à l'effort qu'il faudrait pour faire la recherche pour vous assurer de bien comprendre les implications de faire des codes IATA le champ de clé primaire. Dans certains cas, non seulement je m'en fiche, mais je ne veux pas me soucier des codes IATA. Le commentaire de @James Snell ci-dessous est un exemple parfait de quelque chose que je ne voudrais peut-être pas avoir à craindre d'affecter le PK de mes tables.
En outre, la cohérence de la conception est importante. Si vous avez une base de données avec des dizaines de tables qui ont toutes systématiquement conçu des clés de substitution, puis quelques tables de recherche qui utilisent des codes tiers comme PK, cela introduit une incohérence. Ce n'est pas tout à fait mauvais, mais cela nécessite une attention supplémentaire dans la documentation et ce qui peut ne pas être garanti. Ce sont des tables de recherche pour l'amour de Dieu, il est tout à fait correct d'utiliser une clé de substitution pour la cohérence.
Mise à jour basée sur des recherches supplémentaires:
Ok, la curiosité m'a mordu et j'ai décidé de faire des recherches sur les codes d'aéroport IATA pour le plaisir, en commençant par les liens fournis dans la question.
Il s'avère que les codes IATA ne sont pas aussi universels et faisant autorité que la question le fait croire. Selon cette page :
La plupart des pays utilisent des codes OACI à quatre caractères , et non des codes IATA, dans leurs publications aéronautiques officielles.
De plus, les codes IATA et les codes OACI sont distincts des codes d'identification FAA , qui sont encore une autre façon d'identifier les aérodromes.
Mon objectif n'est pas de lancer un débat sur les codes qui sont meilleurs ou plus universels ou plus autoritaires ou plus complets, mais de montrer exactement pourquoi concevoir votre structure de base de données autour d'un identifiant tiers arbitraire n'est pas quelque chose que je choisirais de faire. , à moins qu'il n'y ait une raison commerciale spécifique de le faire .
Dans ce cas, je pense que ma base de données serait mieux structurée, plus stable et plus flexible, en renonçant aux codes IATA (ou à tout code tiers, potentiellement modifiable) en tant que candidat de clé primaire et en utilisant une clé de substitution. Ce faisant, je peux renoncer à tous les pièges potentiels qui pourraient survenir en raison de la sélection de la clé primaire.
