Penso che bisogno sia una parola molto forte e, in senso stretto, i tavoli probabilmente non hanno bisogno di chiavi surrogate .
Tuttavia, se fosse il mio database, probabilmente aggiungerei comunque le chiavi surrogate. Potrei non voler necessariamente che il mio progetto di database dipenda da un gruppo di terze parti (IATA, ISO), indipendentemente da quanto siano stabili i loro standard. Oppure, potrei non voler dipendere da un particolare standard (ci sono altri standard di codice valuta? Non lo so). Probabilmente modellerei le mie tabelle con chiavi surrogate in questo modo:
+-------------------------+ +------------------------+
|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 |
+-------------------------+
In altre parole, a meno che quei codici standard del settore non siano intrinsecamente importanti per la mia applicazione, non li userei come PK delle mie tabelle. Sono solo etichette. La maggior parte delle altre mie tabelle avrà probabilmente chiavi surrogate comunque, e questa configurazione aggiungerebbe coerenza al mio modello di dati. Il costo dell '"aggiunta" delle chiavi surrogate è minimo.
Aggiornamento basato su alcuni dei commenti:
Senza conoscere il contesto delle tabelle di esempio, è impossibile sapere quanto importanti siano i codici aeroportuali IATA per l'applicazione che utilizza il database. Ovviamente, se i codici IATA sono di importanza centrale e utilizzati in modo pervasivo in tutta l'applicazione, potrebbe essere la decisione corretta, dopo un'analisi adeguata, di utilizzare i codici come PK della tabella.
Tuttavia, se la tabella è solo una tabella di ricerca utilizzata in alcuni angoli dell'app, l'importanza relativa dei codici IATA potrebbe non giustificare un punto così importante nell'infrastruttura del database. Certo, potresti dover fare un ulteriore join in alcune query qua e là, ma tale sforzo potrebbe essere banale rispetto allo sforzo che ci vorrebbe per fare la ricerca per assicurarti di comprendere appieno le implicazioni del rendere i codici IATA il campo chiave primaria. In alcuni casi, non solo non mi interessa, ma non voglio preoccuparmi dei codici IATA. Il commento di @James Snell qui sotto è un perfetto esempio di qualcosa che non potrei voler preoccuparmi di influenzare il PK dei miei tavoli.
Inoltre, la coerenza nel design è importante. Se si dispone di un database con decine di tabelle che hanno tutte chiavi surrogate progettate in modo coerente e quindi alcune tabelle di ricerca che utilizzano codici di terze parti come PK, ciò introduce un'incoerenza. Non è del tutto negativo, ma richiede un'attenzione particolare nella documentazione e tale che potrebbe non essere giustificato. Sono tabelle di ricerca per l'amor del cielo, solo usare una chiave surrogata per coerenza va benissimo.
Aggiornamento basato su ulteriori ricerche:
Ok, la curiosità mi ha morso e ho deciso di fare qualche ricerca sui codici aeroportuali IATA per divertimento, a partire dai link forniti nella domanda.
A quanto pare, i codici IATA non sono così universali e autorevoli come la domanda li rende. Secondo questa pagina :
La maggior parte dei paesi utilizza codici ICAO a quattro caratteri , non codici IATA, nelle loro pubblicazioni aeronautiche ufficiali.
Inoltre, i codici IATA e ICAO sono distinti dai codici identificativi FAA , che rappresentano ancora un altro modo per identificare i campi di aviazione.
Il mio punto di vista non è quello di iniziare un dibattito su quali codici siano migliori o più universali o più autorevoli o più completi, ma mostrare esattamente perché progettare la struttura del database attorno a un identificatore di terze parti arbitrario non è qualcosa che sceglierei di fare , a meno che non vi fosse un motivo commerciale specifico per farlo .
In questo caso, ritengo che il mio database sarebbe meglio strutturato, più stabile e più flessibile, rinunciando ai codici IATA (o qualsiasi codice di terze parti, potenzialmente modificabile) come candidato chiave principale e usando una chiave surrogata. In questo modo, posso rinunciare a eventuali insidie che potrebbero sorgere a causa della selezione della chiave primaria.
