I’d like to talk a little bit about how currencies, countries and languages are treated in databases, and also show how they could be represented in Minimal Modeling.
Firstly, a Foreign Key (FK) can also be based on an UNIQUE Key, aka Alternate Key (AK). I still used a "traditional" PRIMARY KEY (PK) on "lookup" tables for things like countries and currencies while using the character code-based AK as the basis for FKs. This ensured only valid values were used, but avoided a fetch on the "lookup" table to map the PK to the code. It also allowed "housekeeping" mechanisms to still generically refer to rows in those tables, like all the others, via a tuple { <tablename>, <PK#> }.
Secondly, while the ISO codes for country and currency may be point-in-time unique, **they are not guaranteed to be historically unique**. Unless the standards have changed since I last looked at them, each had provisions (para 6.4.1 in my copy of ISO 3166 for countries, para A.5.2.3 in my copy of ISO 4217 for currencies) against reuse within 5 years. Interestingly, the former says "... should not be used ...", the latter "... will reserve ...".
When Brazil's currency was volatile in the late 1980s (https://en.wikipedia.org/wiki/Brazilian_currency), they went from Cruzados (BRC) to New Cruzados (BRN) to Cruzeiros in just a few years, for which they suggested returning to BRC. Fortunately, the business manager with whom I worked was the Currency Code "gatekeeper" at the time, and knew of my concerns about code reuse. He promised it wouldn't happen on his watch, and his suggestion of BRE for Cruzeiros was accepted by the Brazilians.
Firstly, a Foreign Key (FK) can also be based on an UNIQUE Key, aka Alternate Key (AK). I still used a "traditional" PRIMARY KEY (PK) on "lookup" tables for things like countries and currencies while using the character code-based AK as the basis for FKs. This ensured only valid values were used, but avoided a fetch on the "lookup" table to map the PK to the code. It also allowed "housekeeping" mechanisms to still generically refer to rows in those tables, like all the others, via a tuple { <tablename>, <PK#> }.
Secondly, while the ISO codes for country and currency may be point-in-time unique, **they are not guaranteed to be historically unique**. Unless the standards have changed since I last looked at them, each had provisions (para 6.4.1 in my copy of ISO 3166 for countries, para A.5.2.3 in my copy of ISO 4217 for currencies) against reuse within 5 years. Interestingly, the former says "... should not be used ...", the latter "... will reserve ...".
When Brazil's currency was volatile in the late 1980s (https://en.wikipedia.org/wiki/Brazilian_currency), they went from Cruzados (BRC) to New Cruzados (BRN) to Cruzeiros in just a few years, for which they suggested returning to BRC. Fortunately, the business manager with whom I worked was the Currency Code "gatekeeper" at the time, and knew of my concerns about code reuse. He promised it wouldn't happen on his watch, and his suggestion of BRE for Cruzeiros was accepted by the Brazilians.