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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
