4 ms·
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 t
by ericHosick 4y ago
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 4y ago> 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 4y agoYes, 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.