I was reading the mysql manual and want to make sure I understanding something correctly.
If I have DECIMAL (15,8) would this mean 6 digital before the decimal and 8 after?
If I want to move from 15,2 to allow for 8 decimals after price, then should I move to 21,8 so I don't lose any precision?
From mysql documentation : http://dev.mysql.com/doc/refman/5.7/en/fixed-point-types.html
In a DECIMAL column declaration, the precision and scale can be (and usually is) specified; for example:
salary DECIMAL(5,2)
In this example, 5 is the precision and 2 is the scale. The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Standard SQL requires that DECIMAL(5,2) be able to store any value with five digits and two decimals, so values that can be stored in the salary column range from -999.99 to 999.99.
Related
I have mysql DB with important financial data, currently the data is stored as float type and I get incorrect data due to float rounding, I want to store it as DECIMAL.
What is the safe way to convert the data in the DB without change existing data? or any another idea to solve that issue?
EDIT: Does converting from FLOAT to VARCHAR and than from VARCHAR to DECIMAL is a safe way?
Thanks in advance!
13815500 is exactly representable in FLOAT. But you are close to what Andrew talks about -- 16777217 is not exactly representable; it will be off by 1 Euro or dollar or whatever.
If you have no decimal places, your choices are
FLOAT, which messes up above 16,777,216.
DECIMAL(9,0) which can handle numbers up to about 1 billion. Caveat: If you need decimal places, say so!_
INT which peaks at about 2 billion.
INT UNSIGNED - limit about 4 billion (non-negative values only).
Each of the above datatypes mentioned above takes 4 bytes. All but the last allow for negative values. FLOAT will keep going, but lose bits at the bottom; the others "overflow".
Other options: DECIMAL(m,0) with bigger numbers (m<=64), DOUBLE (huge floating range), BIGINT (huge integral range); each take more space.
The syntax is
ALTER TABLE tablename
MODIFY col_name NEW_DATATYPE [NOT NULL];
(There is no need, and may be harm, in stepping through VARCHAR.)
General rule: Use DECIMAL for money because it is "exact"; use FLOAT for measurements (such as sensors, distance, etc)
More
If the max value is 13815500, then DECIMAL(64,56) will hold any of your numbers, and handle up to 56 decimal places. Furthermore, you can do basic arithmetic exactly on those numbers. Caution: If you will be SUMming a thousand such numbers, you need an extra 3 digits before the decimal point: DECIMAL(64,53). For summing a million numbers: DECIMAL(64,50).
If your current data is sitting in a FLOAT column, then you only have about 7 significant digits; the rest was lost as the numbers were stored. Can you recover the lost precision? If so, start over with a suitable DECIMAL. If not, then a numerical analyst will argue that you may as well stick with FLOAT. A SUM will still be good to about 6-7 significant digits. This is good enough for most uses.
You now have virtually all the knowledge of MySQL and numerical analysis; you decide what to do.
There is no safe way. Due to how floats work, 32 bit floats greater than 16777216 (or less than -16777216) need to be even, greater than 33554432 (or less than -33554432) need to be evenly divisibly by 4, greater than 67108864 (or less than -67108864) need to be evenly divisibly by 8, etc.
The infamous question about datatypes when storing money values in an SQL database.
However in these trying times, we now have currencies that have worth up to 18 decimal places (thank you ETH).
This now reraises the classic argument.
IDEAS
Option 1 BIGINT Use a big integer to save the real value, then store how many decimal places the currency has (simply dividing A by 10^B in translation)?
Option 2 Decimal(60,30) Store the datatype in a large decimal, which inevitibly will cost a large amount of space.
Option 3 VARCHAR(64) Store in a string. Which would have a performance impact.
I want to know peoples thoughts and what they are using if they are dealing with cryptocurrency values. As I am stumped with the best method for proceeding.
There's a clear best option out of the three you suggested (plus one from the comments).
BIGINT — uses just 8 bytes, but the largest BIGINT only has 19 decimal digits; if you divide by 1018, the largest value you can represent is 9.22, which isn't enough range.
DOUBLE — only has 15–17 decimal digits of precision; has all the known drawbacks of floating-point arithmetic.
VARCHAR — will use 20+ bytes if you're dealing with 18 decimal places; will require constant string↔int conversions; can't be sorted; can't be compared; can't be added in DB; many downsides.
DECIMAL(27,18) – if using MySQL, this will take 12 bytes (4 for each group of 9 digits). This is quite a reasonable storage size, and has enough range to support amounts as large as one billion or as small as one Wei. It can be sorted, compared, added, subtracted, etc. in the database without loss of precision.
I would use DECIMAL(27,18) (or DECIMAL(36,18) if you need to store truly huge values) to store cryptocurrency money values.
Good day, I am confused with the datatype for MySQL.
I am using decimal as apparently it is the safest bet for accuracy in a business application. However, I find that when fields are returned I have values of 999999999.99, where my datatype is DECIMAL(10,2). So the actual value has overflowed outside the (10, 2) parameter.
Would it be correct that even though I have specified 10 places before the comma and 2 places after the comma. MySQL still stores the complete number?
Also would it be possible to turn off the maximum amount of digits displayed before and after the comma?
Would it be correct that even though I have specified 10 places before the comma and 2 places after the comma. MySQL still stores the complete number?
No, it wouldn't.
First, you specified 10 digits altogether; two are to the right of the decimal point, and eight are to the left.
Standard SQL requires that DECIMAL(5,2) be able to store any value with five digits and two decimals, so values that can be stored in the salary column range from -999.99 to 999.99.
Second, MySQL will silently convert the least significant digits to scale if there are more than two. That will probably look like MySQL truncates, but the actual behavior is platform-dependent. It will raise an error if you supply too many of the most significant digits.
Finally, when you're working with databases, the number of digits displayed has little to do with what a data type is or with what range of values it stores.
I need to store a large volume of small decimals numbers (3 digits before the decimal, 6 digits after the decimal).
From my understanding of the spec, this will require 8 bytes. I could store the number as an int which requires only 4 bytes and convert after retrieval using a fixed scale factor.
Is there a better alternative instead of using an int, I can't easily do any arithmetic on the numbers?
Thanks.
I do not think this is correct.
DECIMAL(9,6) should do the job.
It will require 2 bytes for the 3 digits and 3 bytes for the 6 digits according to mysql 5.1 manual. IMHO that´s 5 bytes not 8 bytes in total.
You will therefore not require a lot more memory than with the integer "hacking" you proposed. I would definitely go with decimal in your case.
No, it won't work if you are using "int" data type of MySQL. This is because integers can't handle decimal precision.
According to your question, you should be using "Fixed Point Data Types", which will benefit you in large calculations & monetary data. In MySQL, the required data type is "DECIMAL" and you can read more on it here.
The proper syntax in you case will be "DECIMAL (9, 6)", where 9 means that values can be stored with up to 9 digits in total, of which 6 digits are after the decimal point and 3 digits are before the decimal point.
Hope it helps.
DECIMAL is supposed to be exact. It isn't. It rounds like crazy!
TABLE:
account_balance DECIMAL(18,4)
If I insert 43210987654321.9999
it rounds to 43210987654322.0000
If I insert 43210987654321.9876
it rounds to 43210987654321.9840
WHY? If I use numbers larger than 18 during table creation it is even worse.
EDIT:
I posted this clarification edit because some people do not know about the DECIMAL data type.
The DECIMAL data type is a FIXED POINT data type as opposed to a FLOATING POINT data type.
The reason it is used is:
(1) Store massive numbers that have decimal values with exact precision.
(2) Prevent rounding errors that can not be prevented when using floating point calculations. Thus any calculation on DECIMAL values should be exact... no rounding error.
POSTRESQL
http://www.postgresql.org/docs/8.1/static/datatype.html
numeric -- user-specified precision -- exact --no limit
The type numeric can store numbers with up to 1000 digits of precision and perform calculations exactly. It is especially recommended for storing monetary amounts and other quantities where exactness is required. However, arithmetic on numeric values is very slow compared to the integer types, or to the floating-point types described in the next section.
The types decimal and numeric are equivalent. Both types are part of the SQL standard.
MySQL
DECIMAL( , ) A DOUBLE stored as a string , allowing for a fixed decimal point.
http://www.htmlite.com/mysql003.php
MySQL DOC
Fixed-Point (Exact-Value) Types
The DECIMAL and NUMERIC types store exact numeric data values. These types are used when it is important to preserve exact precision, for example with monetary data. In MySQL, NUMERIC is implemented as DECIMAL, so the following remarks about DECIMAL apply equally to NUMERIC.
As of MySQL 5.0.3, DECIMAL values are stored in binary format. Previously, they were stored as strings, with one character used for each digit of the value.
http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
The maximum value of 65 for M means that calculations on DECIMAL values are accurate up to 65 digits. This limit of 65 digits of precision also applies to exact-value numeric literals, so the maximum range of such literals differs from before. (In older versions of MySQL, decimal values could have up to 254 digits. However, calculations were done using floating-point and thus were approximate, not exact.)
Calculations involving exact-value decimal numbers are accurate to 65 digits. This is fewer than the maximum number of digits permitted before MySQL 5.0.3 (254 digits), but the exact-value precision is greater. Calculations formerly were done with double-precision floating-point, which has a precision of 52 bits (about 15 decimal digits).
http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html
I tested on my local mysql 5.1.36 and it does not round.
What version are you using.
Also, what are you using to insert. Are you sure it is mysql rounding and not the storage before inserting to mysql.