What is the best way to store a money value in the database?

Question

I've created a custom IEF policy and uploaded this to my tenant. This works fine calling it from the Azure portal and I can see the JWT output which has a signature as this

From IEF application
{
  "typ": "JWT",
  "alg": "HS256",
  "kid": "XXXXXXXXXXXXX_XXXXXXXCSY"
}

However if I do a file>new .net core web project and use my B2C application id (Not my IEF one) and call the policy I get an error on the callback

Signature validation Unable to match key kid: '[PII is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.

Comparing the 2 JWTs generated, there is a difference in the signature

From B2C application
{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "XXXXXXXXXXXXXXX-XXXXXXXNk"
}

I'm assuming my web app needs to validate a different issuer of the token. I've seen some information regarding a 'discovery' url, but how to do this using the out-of-the-box web solutions? I couldn't find much info on this at all.

Solution 1

Decimal and money ought to be pretty reliable. What i can assure you (from painful personal experience from inherited applications) is DO NOT use float!

Solution 2

I always use Decimal; never used MONEY before.

Recently, I found an article regarding decimal versus money data type in Sql server that you might find interesting:

Money vs Decimal

It also seems that the money datatype does not always result in accurate results when you perform calculations with it : click

What I've done as wel in the past, is using an INT field, and store the amount in cents (eurocent / dollarcent).

Solution 3

I guess it comes down to precision and scale. IIRC, money is 4dp. If that is fine, money expresses your intent. If you want more control, use decimal with a specific precision and scale.

Solution 4

It depends on your application!!! I work in financial services where we normally consider price to be significant to 5 decimal places after the point, which of course when you buy a couple of million at 3.12345pence/cents is a significant amount. Some applications will supply their own sql type to handle this.

On the other hand, this might not be necessary. <Humour> Contractor rates always seemed to be rounded to the nearest £100, but currently seem to be to nearest £25 pounds in the current credit crunch. </Humour>

Solution 5

Don't align your thoughts based on available datatypes. Rather, analyze your requirement and then see which datatype fits best. Float is anytime the worst choice considering the limitation of the architecture in storing binary version of floating point numbers. Money is a standard unit and will surely have more support for handling money related operations. In case of decimal, you'll have to handle each and everything but you know it's only you who is handling a decimal type, thus no surprises which you may get with other two data types.

View more solutions