Jump to content

Recommended Posts

Please be aware - I didn't set this up.  Not a problem to alter/edit/nuke though  :D

 

I have a database with a set of price fields for auctions - with starting, buyitnow, reserve, makeanoffer_min and makeanoffer_auto.

 

All of these fields deal with financial amounts.  None of the amounts will include pence, so it will never have 1.99, but would be either 1 or 2.

 

All of these fields are set to 'double' in mysql except for the last one (auto) which is set to decimal(10,0). 

 

I believe we've spotted a problem where one item has a reserve of £2,012,000 - but the database has stored the reserve as 2.  Is this correct for double?

 

I don't realy understand single and double-precision numbers, something I'm off to try and figure out..  But any help on formats for these fields would be great.

Link to comment
https://forums.phpfreaks.com/topic/254396-double-vs-decimal-for-currency-amounts/
Share on other sites

Well if it's a "real" auction site with bid increments, the company controls the increments and there aren't ever decimals in the bid column.  I worked at a "real" auction house and all our bids were round numbers.

Well if it's a "real" auction site with bid increments, the company controls the increments and there aren't ever decimals in the bid column.  I worked at a "real" auction house and all our bids were round numbers.

There's a only a minor storage difference (one byte), so strictly speaking I suppose you're correct.  But the fact that dollar amounts are being stored as integers bothers me to no end.

True, but with floating point errors some companies (mine included) store even cents as whole numbers.  We just divide by 100 when we display them.

There shouldn't be any floating-point errors with DECIMAL -- at least not the same as with DOUBLE / FLOAT -- but I haven't really bothered to check.

Not in the DB, no, but in the programming language.  We get weird 2.1300000001 results sometimes.

 

They're rare, obviously, but we're a payment processor that works in two dozen currencies, storing everything as whole numbers and storing a "divisor" next to it is safer.

Not in the DB, no, but in the programming language.  We get weird 2.1300000001 results sometimes.

 

They're rare, obviously, but we're a payment processor that works in two dozen currencies, storing everything as whole numbers and storing a "divisor" next to it is safer.

Well, yes, all numbers need to be rounded as soon as there's multiplication with decimals.

 

But even the divisor solution won't help with taxes, and such, right?

Taxes are where we run into the most problems.  We end up with fractions of a rupee or a yen, and they don't do fractional currencies.  However, that's why we round.  The only time decimals are a real problem is for display purposes, where we have to do weird things.

 

DECIMAL data types are good enough for the most part, since at some point you need to turn a whole number into a decimal for most applications.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.