Native support for currencies

[siljamardla]

Any company that operates across multiple countries, knows the inconveniences related to constantly working with different currencies.

In the end, the process is extremely standard. For any given monetary metric, we need to know:

• what currency is the field value represented in
• what is the date (time) of this particular field related to (e.g. a transaction happened on Jan 1st)
• where is the currency exchange rate stored and what's the structure of this table (e.g. SCD type 2 with valid from, valid to, from currency to currency and the rate itself)
• if necessary, which exchange rate type to use (central bank rate, mid-market whatever rate etc)

Ideally, every monetary metric should therefore have additional fields to mark it as monetary and indicate which field marks the currency for this metric. From there, the query engine could already pick up and automatically do the appropriate join and conversion. The user could simply request the metric in a specific currency. The conversion would be handled behind the scenes without the data team explicitly handling every single conversion case.

[kurtStirewalt]

This idea is similar in spirit to 42 in that different currencies can be thought of abstractly as different units of measure, and I suspect we generally want to parameterize metrics by unit of measure so that the desired unit can be specified at query time.

It's also similar to 44 in that when you are querying a metric with a particular currency, you also need to specify which temporal attribute to use to get the timestamp (or date) for looking up the exchange rate (the default being to use today's date if no temporal attribute is specified in the query).