I often wonder about this kind of solution compared with a more traditional solution of using a table of columns and constraints. There seems like there should be an obvious heuristic of when to use one or the other but it eludes me.
In most cases, a single invoice, order, deal, etc. is unlikely to be generated using multiple currencies. Therefore, a single currency_type field in the invoice table would be sufficient.
If we used a composite currency type, the currency_type field would be highly redundant.
It can help prevent the bug in which someone adds up multiple currencies without conversion.
“25 USD + 25 EUR” will either fail or work via some currency conversion routine.
“25 + 25” will produce a meaningless and useless wrong answer.
For example, SemVer requires that two version that differ only in metadata e.g. `1.0.0+metaA` and `1.0.0+metaB` should be considered equal. It would be error prone and tedious to push that logic onto every query that wanted to sort the table, but with a type we can define the logic once and have it work everywhere.