Eu acho que necessidade é uma palavra muito forte e, em sentido estrito, as tabelas provavelmente não precisam de chaves substitutas .
No entanto, se fosse meu banco de dados, provavelmente adicionaria chaves substitutas de qualquer maneira. Talvez eu não queira necessariamente que meu design de banco de dados dependa de vários terceiros (IATA, ISO), independentemente de quão estáveis sejam seus padrões. Ou talvez eu não queira depender de um padrão específico (existem outros padrões de código de moeda? Não sei). Eu provavelmente modelaria minhas tabelas com chaves substitutas da seguinte forma:
+-------------------------+ +------------------------+
|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 |
+-------------------------+
Em outras palavras, a menos que esses códigos padrão da indústria sejam inerentemente importantes para o meu aplicativo, eu não os usaria como o PK das minhas tabelas. Eles são apenas rótulos. A maioria das minhas outras tabelas provavelmente terá chaves substitutas de qualquer maneira, e essa configuração adicionaria consistência ao meu modelo de dados. O custo de 'adicionar' as chaves substitutas é mínimo.
Atualização baseada em alguns dos comentários:
Sem conhecer o contexto das tabelas de exemplo, é impossível saber o quão importantes são os códigos de aeroporto IATA para o aplicativo usando o banco de dados. Obviamente, se os códigos IATA são de importância central e usados de maneira generalizada em todo o aplicativo, pode ser a decisão correta, após análise adequada, usar os códigos como PK da tabela.
No entanto, se a tabela for apenas uma tabela de pesquisa usada em alguns cantos do aplicativo, a importância relativa dos códigos IATA pode não justificar um ponto tão proeminente na infraestrutura do banco de dados. Claro, talvez você precise fazer uma junção adicional em algumas consultas aqui e ali, mas esse esforço pode ser trivial em comparação com o esforço necessário para fazer a pesquisa para garantir que você compreenda completamente as implicações de tornar os códigos IATA os campo de chave primária. Em alguns casos, não só eu não ligo, mas não quero ter que me importar com os códigos IATA. O comentário de @James Snell abaixo é um exemplo perfeito de algo que talvez eu não queira se preocupar em afetar o PK das minhas tabelas.
Além disso, a consistência no design é importante. Se você possui um banco de dados com dezenas de tabelas que projetam consistentemente chaves substitutas e algumas tabelas de pesquisa que usam códigos de terceiros como PK, isso introduz uma inconsistência. Isso não é totalmente ruim, mas requer atenção extra na documentação e em outras que possam não ser justificadas. Eles são tabelas de pesquisa por amor de Deus, basta usar uma chave substituta para garantir a consistência.
Atualização baseada em pesquisas adicionais:
Ok, a curiosidade me mordeu e decidi fazer uma pesquisa sobre os códigos do aeroporto da IATA por diversão, começando pelos links fornecidos na pergunta.
Como se vê, os códigos IATA não são tão universais e autoritários quanto a pergunta os torna. De acordo com esta página :
A maioria dos países usa códigos ICAO de quatro caracteres , e não códigos IATA, em suas publicações aeronáuticas oficiais.
Além disso, os códigos IATA e ICAO são diferentes dos códigos de identificação FAA , que são outra maneira de identificar os aeroportos.
Meu ponto de vista é não iniciar um debate sobre quais códigos são melhores ou mais universais ou mais autoritativos ou mais abrangentes, mas mostrar exatamente por que projetar sua estrutura de banco de dados em torno de um identificador de terceiros arbitrário não é algo que eu escolheria fazer , a menos que haja um motivo comercial específico para fazer isso .
Nesse caso, acho que meu banco de dados ficaria melhor estruturado, mais estável e mais flexível, renunciando aos códigos IATA (ou qualquer código potencialmente alterável de terceiros) como candidato à chave primária e usando uma chave substituta. Ao fazer isso, posso renunciar a possíveis armadilhas que possam surgir devido à seleção da chave primária.
