Shane Ambler wrote:
> August Zajonc wrote:
>
>> Agreed with Tom on this one. Full usage of money is beyond tagged types
>> etc. For example, when you earn money in another currency, it is the
>> time at which you earn it that describes its value. So for P&L accounts
>> there is generally no change in exchange rates over time and you need to
>> track what the rate was at time of earning. Solution is to date earnings
>> and have a table of exchange rates by day.
>
>
> Personally I think a true money type should hold the numeric value and
> optionally the currency (similar to the timestamp with timezone) and
> have support functions that handle the i/0 conversion (text -
> $US1,000.00 - to money) as happens now. As opposed to the db designer
> storing it in different columns.
It'd be nice if there were an easy, standard solution to this problem-
but I don't think there is. For example, our application (which would
be greatly simplified if there was a standard solution to this) knows of
~200 different currencies, including such standards as the Uganda
Shilling, the Zambia Kwacha, and Ethiopian Birr. Not to mention you get
situations where goverments (for various reasons) issue "new" currency,
like the "new" Zimbabwe Dollar, vr.s the "old" Zimbabwe Dollar. Confuse
these two and you'll lose your shirt.
Personally, I don't think it's that big of a deal to have to do in my
queries: SELECT table.amount || ccy.code FROM table LEFT JOIN lu_currency AS ccy WHERE
table.ccy_id= ccy.id
to make the report come out as "1000000USD".
Brian