Penso che bisogno sia una parola molto strong, e in senso stretto, le tabelle probabilmente non bisogno di chiavi surrogate .
Tuttavia, se fosse il mio database, probabilmente aggiungerei le chiavi surrogate comunque. Potrei non volere necessariamente che la mia progettazione 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 uno standard particolare (ci sono altri standard di codici valutari? 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 siano intrinsecamente importanti per la mia applicazione, non li userei come PK dei miei tavoli. Sono solo etichette. La maggior parte delle altre mie tabelle probabilmente avrà comunque chiavi surrogate e questa configurazione aggiungerebbe consistenza al mio modello di dati. Il costo dell'aggiunta delle chiavi surrogate è minimo.
Aggiornamento basato su alcuni commenti:
Senza conoscere il contesto delle tabelle di esempio, è impossibile sapere quanto siano importanti le cose come IATA Airport Codes per l'applicazione che utilizza il database. Ovviamente, se i codici IATA sono centralmente importanti e utilizzati in modo pervasivo all'interno dell'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 una posizione così prominente nell'infrastruttura del database. Certo, potrebbe essere necessario fare un ulteriore join in alcune query qua e là, ma questo sforzo potrebbe essere banale in confronto allo sforzo necessario per fare la ricerca per assicurarti di comprendere appieno le implicazioni di 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 di seguito è un perfetto esempio di qualcosa che potrei non voler preoccupare di influenzare il PK dei miei tavoli.
Inoltre, la coerenza nel design è importante. Se si dispone di un database con dozzine di tabelle che dispongono tutte di chiavi surrogate coerentemente progettate e quindi di alcune tabelle di ricerca che utilizzano codici di terze parti come PK, ciò introduce un'incoerenza. Ciò non è del tutto negativo, ma richiede un'attenzione supplementare nella documentazione e tale che potrebbe non essere giustificato. Sono tabelle di ricerca per carità, solo l'uso di una chiave surrogata per coerenza è perfettamente soddisfacente.
Aggiornamento basato su ulteriori ricerche:
Ok, la curiosità mi ha morso e ho deciso di fare qualche ricerca sui codici aeroportuali IATA per divertimento, iniziando dai link forniti nella domanda.
Come risulta, i codici IATA non sono così universali e autorevoli come la domanda li rende fuori. In base a questa pagina :
Most countries use four-character ICAO codes, not IATA codes, in their
official aeronautical publications.
Inoltre, i codici IATA e ICAO sono diversi dai codici identificativi FAA , che sono ancora un altro modo per identificare gli aeroporti.
Il mio punto di vista è non iniziare un dibattito su quali codici sono migliori o più universali o più autorevoli o più completi, ma per mostrare esattamente perché progettare la struttura del database attorno a un identificatore arbitrario di terze parti non è qualcosa che vorrei scegli di fare, a meno che non ci fosse un motivo aziendale specifico per farlo .
In questo caso mi sento il mio database sarebbe meglio strutturato, più stabile e più flessibile, rinunciando ai codici IATA (o a qualsiasi terza parte, codice potenzialmente modificabile) come candidato chiave principale e utilizzare una chiave surrogata. In tal modo, posso evitare qualsiasi potenziale insidia che potrebbe verificarsi a causa della selezione della chiave primaria.
