We currently have a table row set to INT and a php script that adds the value of 5000 every 60 seconds(cron). We now need the ability include a decimal point.
If we change the addition value of 5000 to say 5000.19, would this work with INT? or do we need to change the row to Decimal?
I hope that makes sense.
Breakdown:
Current Setup
Start Number: 12500 (INT)
Increase Amount: +5000 (No decimal)
We now need it to work with decimals:
Start Number: 12500
Increase Amount: +5000.19 (with decimal)
You could just change the column to "text" or "varchar" as a lazy work around, it will work fine in most circumstances
Yes, you will need to convert the column's data type. INT columns store only integer numbers.
alter table my_table modify time_value decimal(18,4);
Make sure you choose the correct precision and scale values for the decimal type.
Related
I'm using a decimal data type in mysql. I set it to 6,2 but it won't allow 12105. It defaults to 10000 any time a number is inputted higher than 10000. How can I allow numbers like 12105 up to 5000000 and more.
This is a dup but I can't find it. DECIMAL(x,y) means the total number of digits (left OR right of the point) is x.
So, if you want to store between 0 and 999999.99, you need to define it as DECIMAL(8,2)
i've try using varchar, the problems below :
if the points 1000, then minus 10000, it'll not change the value to -9000.
then try again using int, the problems :
points can't have any , (comma) like 10000.21 it'll change the value to 10000
any ideas of this?
Use DECIMAL datatype if you want to use decimals :)
EDIT:
Standard SQL requires that DECIMAL(6,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 -9999.99 to 9999.99
Just use DECIMAL data type.
INT can't be decimal.
EDIT: Yeah, DECIMAL, not DOUBLE.
I have field where i store my grand total to a mysql filed as total and its type set as decimal(10,2)
When my php form adds up and updates the query for 112381348.40 (i.e 112 million)
but when i fetch or view it on phpMyadmin, the value shows as 99999999.99
from my data type set, it has to be 10 digits and 2 decimals where as it is maximum updating as 8 and 2.
Am i understanding wrong or what am i doing wrong.
I know i can increase it to decimal(13,2) and then see it.
But i would like to know the reason, why 10,2 is not happening?
The specification for decimal(m, n) takes two arguments. The first is the "precision" and the second is the "scale". More colloquially, the first is the number of digits in the number. The second is the number of digits to the right of the decimal point.
So, your specification of decimal(10, 2) can store numbers like: 12,345,678.90 -- i.e., up to 99,999,999.99. And that is the maximum number.
If you want to store numbers larger than that, then use a larger precision for the number. For your number, you need at least decimal(11, 2), although I would suggest a larger precision so you don't encounter this problem in the future.
In setting a float or decimal field, the first int value is the total character count. The second is how many decimal places. So:
//decimal(10,2)
12345678.90
//decimal(13,2)
12345678901.23
//decimal(7,3)
1234.567
See?
You have 11 digits. The first number is the total digits. Try:
DECIMAL(11, 2)
PHP runs a script that correctly calculates a value. When I echo that value out it comes out as 4.865472349
Then a simple update script is used to enter the value into my database.
$query = "UPDATE members
SET rating = $r
WHERE username = '$username'";
mysql_query($query);
When I do this, the value that is entered into the database is 5.
If I replace $r in the previous formula with 4.865472349 directly, it produces the same result.
Clearly this is because my SQL type was set to "integer"
But Im not sure what to change it to in order to fix this issue. Any help?
If you want the same precision as 4.865472349, you can use DECIMAL(10,9)
Reference
For example, a DECIMAL(18,9) column has nine digits on either side of the decimal point, so the integer part and the fractional part each require 4 bytes. A DECIMAL(20,6) column has fourteen integer digits and six fractional digits. The integer digits require four bytes for nine of the digits and 3 bytes for the remaining five digits. The six fractional digits require 3 bytes.
Assuming you are using MySql
You probably should use DOUBLE. It has the same precision and range as floating point numbers in PHP (in most configurations).
To switch the type using PHPMyAdmin:
Click on the table
Click on structure
Click on Change (the pencil icon) beside rating
Under "Type" select the option "DOUBLE"
Hit Save
You can use float, double or decimal depending on the numbers you'll be storing. I would say float is good enough.
Edit the column type in the database to be able to hold more than just an integer.
ALTER TABLE members
CHANGE rating rating float(10,9);
I have one PHP script inserting rows in a MySQL database. Each row has a field 'created_at' which is filled with the value of the PHP function microtime(true), and inserted as a double. (microtime because I need something more precise than to the second)
I have another PHP script that selects rows based on that created_at field.
When I go ahead and select like this:
SELECT * FROM `ms_voltage` WHERE created_at > 1302775523.51878
I receive a resultset with, as the first row, the row with exactly that value for created_at.
This occurs from within my PHP script and from within PhpMyAdmin when manually doing the query. But not always, not for every value. Just once and a while really.
How is this possible? I didn't ask for greater than/equals, I want strictly greater than.
Am I overlooking something type-related perhaps?
Yeah, floating point arithmetic can do that sometimes. To understand why, it's helpful to realize that just as not all numbers can be accurately represented in base 10, not all numbers can be accurately represented in base 2 either.
For example, "1/3" may be written in base 10 as 0.33333 or 0.33334. Neither is really "correct"; they're just the best we can do. A "DOUBLE" in base 10 might be 0.3333333333 or 0.3333333334, which is double the digits, yet still not "correct".
The best options are to either use a DECIMAL value, or use an INT value (and multiply your actual values by, say, 10000 or 100000 in order to get the decimal digits you care about into that int).
The DOUBLE type represent only approximate numeric data values. Try to use the DECIMAL type.
Is your column floating point? Calling microtime with true gives you a float, and that looks like a float, which will have digits after the .51878 that you don't see, so those digits make the stored value greater than the value you have in your query.
Unless you really need the float I'd convert the string result to an int, or even two columns for seconds and useconds. Then you can use > or < on known values without worrying about the imprecision of the floating point value.