Creo que necesidad es una palabra muy fuerte, y en un sentido estricto, las tablas probablemente no necesitan claves sustitutas .
Sin embargo, si fuera mi base de datos, probablemente agregaría claves sustitutas de todos modos. Es posible que no necesariamente quiera que el diseño de mi base de datos dependa de un grupo de terceros (IATA, ISO), independientemente de cuán estables sean sus estándares. O bien, es posible que no quiera depender de un estándar en particular (¿hay otros estándares de código de moneda? No lo sé). Probablemente modelaría mis tablas con claves sustitutas así:
+-------------------------+ +------------------------+
|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 otras palabras, a menos que esos códigos estándar de la industria sean inherentemente importantes para mi aplicación, no los usaría como PK de mis tablas. Son solo etiquetas. La mayoría de mis otras tablas probablemente tendrán claves sustitutas de todos modos, y esta configuración agregaría consistencia a mi modelo de datos. El costo de 'agregar' las claves sustitutas es mínimo.
Actualización basada en algunos de los comentarios:
Sin conocer el contexto de las tablas de ejemplo, es imposible saber qué tan importantes son los códigos de aeropuerto IATA para la aplicación que utiliza la base de datos. Obviamente, si los códigos IATA son centralmente importantes y se usan de manera generalizada en toda la aplicación, podría ser la decisión correcta, después de un análisis adecuado, usar los códigos como PK de la tabla.
Sin embargo, si la tabla es solo una tabla de búsqueda que se utiliza en algunos rincones de la aplicación, la importancia relativa de los códigos IATA puede no justificar un lugar tan destacado en la infraestructura de la base de datos. Claro, es posible que tenga que hacer una unión adicional en algunas consultas aquí y allá, pero ese esfuerzo puede ser trivial en comparación con el esfuerzo que tomaría hacer la investigación para asegurarse de que comprende completamente las implicaciones de hacer que los códigos IATA campo de clave primaria. En algunos casos, no solo no me importa, sino que no quiero tener que preocuparme por los códigos IATA. El comentario de @James Snell a continuación es un ejemplo perfecto de algo de lo que podría no tener que preocuparme para afectar el PK de mis tablas.
Además, la consistencia en el diseño es importante. Si tiene una base de datos con docenas de tablas que han diseñado consistentemente claves sustitutas, y luego algunas tablas de búsqueda que usan códigos de terceros como PK, eso introduce una inconsistencia. Eso no es del todo malo, pero requiere atención adicional en la documentación y tal cosa que no esté justificada. Son tablas de búsqueda por amor de Dios, simplemente usando una clave sustituta para la consistencia está perfectamente bien.
Actualización basada en investigaciones adicionales:
Ok, la curiosidad me mordió y decidí investigar un poco sobre los códigos del aeropuerto IATA por diversión, comenzando con los enlaces provistos en la pregunta.
Resulta que los códigos IATA no son tan universales y autorizados como la pregunta los hace ser. De acuerdo con esta página :
La mayoría de los países utilizan códigos ICAO de cuatro caracteres , no códigos IATA, en sus publicaciones aeronáuticas oficiales.
Además, los códigos IATA y los códigos ICAO son distintos de los códigos identificadores de la FAA , que son otra forma de identificar los aeródromos.
Mi objetivo al mencionar esto no es comenzar un debate sobre qué códigos son mejores o más universales o más autoritarios o más completos, sino mostrar exactamente por qué diseñar su estructura de base de datos en torno a un identificador arbitrario de terceros no es algo que elegiría hacer , a menos que haya una razón comercial específica para hacerlo .
En este caso, creo que mi base de datos estaría mejor estructurada, más estable y más flexible, al renunciar a los códigos IATA (o cualquier código de terceros potencialmente modificable) como candidato de clave principal y usar una clave sustituta. Al hacerlo, puedo renunciar a posibles dificultades que puedan surgir debido a la selección de clave principal.
