MySQL schema design - how to decide between an `enum` vs. a table join
(Yes, there have been many heated discussions of ENUM vs TINYINT vs VARCHAR, both here and on stackoverflow.com.  I have put my 2-cents in on some of them.  I am addressing this Question to discuss nuances of the examples brought up.)

Currency is a tricky one.  When, for example, a devaluation occurs, does the currency_code change?

If so, then is the question is about how often the list of values is likely to change.

If it does not change, then you may have a mess for the data -- Is "XYZ", the old xyz currency, or the 'new'?

With things like country_code (with well-established 2-letter codes) and currency_code (3 letter standard), etc, I recommend using things like

country_code  CHAR(2) CHARACTER SET ascii
currency_code CHAR(3) CHARACTER SET ascii


Rationale:


Only 2 or 3 bytes, which is not much bigger than a 1-byte ENUM or TINYINT.
Avoids the extra bulk and overhead of utf8mb4, which might be the default for the table.
You can still build a secondary table to, for example, spell out the full name of the country or currency.
You won't need a JOIN except when you want the extra info.  (JOINing is most costly when you need to start from multiple Dimension tables in an attempt to look up rows in the Fact table.  A JOIN is reasonably cheap going the other direction.)