[ericHosick]

A good heuristic to consider when designing composite types is whether any part of the type would lead to redundant storage. For example, a currency composite type might consist of an amount field and a type field.

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.

[skissane]

> 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.

[doctor_eval]

Yes, this is exactly what I’ve done previously. For example, I implemented a sum() aggregate function that took “monetary” (currency + value) composite types and raised an exception if the currencies were not all the same.