BackgroundI have this tables+-------------------------+  +------------------------+|Airport                  |  |Country                 ||-------------------------|  |------------------------||airport_code string (PK) |  |country_code string (PK)||address string           |  |name string             ||name  string             |  +------------------------++-------------------------++-------------------------+|Currency                 ||-------------------------||currency_code string (PK)||name string              |+-------------------------+airport_code is the IATA (International Air Transport Association ) airport code, you can see them in your luggage tags when you travel by plane.country_code is the ISO 3166-1 A3 standard country code, you can see them in the olympics.currency_code is the IS0 417 standard 3-chars currency code, you can see them in international currency exchange display boards.QuestionsAre these natural PKs good enough ?Is using world respected standards, which are accepted by whole industries good enough for PKs ?Do this tables need surrogates no matter what ?
Do these specific tables need surrogate keys?
design;database design;relational database;rdbms;surrogate keys
No, they don't.  Those keys are definitely good enough!They're unique, not rarely going to change, and meaningful, which is a step up over a surrogate key.  That's pretty much the definition of a good PK.The restrictions about PKs being immutable and numeric-integer are not part of the Relational Model (Codd's) or any SQL standard (ANSI or other).