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:
      table.amount || ccy.code
      lu_currency AS ccy
      WHERE table.ccy_id =

to make the report come out as "1000000USD".


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to