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)
Related
I have an age column that is currently varchar because i cannot figure out how to define it correctly.
the ages look like the following samples:
.03 / .3 / 1.33 / 20
i tried Decimal (4,2) but then i get something like 82.00! which i dont want.
I want under 1 to look like 0.2 or .2, or .25
I want age 82 to be just 82 and age 5 to be just 5.
do I have to do this in php after the case or is there a way to store the numbers without the extra 0's.
storing as varchar displays them correctly but does not allow for the proper search.
How you store a number and how you format it when printing it are not mutually exclusive things. Storing numbers as strings is about the worst thing you can do. Decimal(4,2) tells MySQL to store the number with up to 2 digits of precision for the integral part of your number and up to 2 digits of precision for the fractional part. This says nothing about how those digits can be printed, however. For example printf("%d", 1.01) gives you 1. Whereas printf("%.2f", 1.0123) gives you 1.01.
PHP has several functions that can assist with formatting such as sprintf, and number_format, not to mention Intl's NumberFormatter for i18n.
If all you want is to truncate the right-most 0s from the number when printing it you can try something like rtrim($number, '0.').
echo rtrim(1.00, '0.'); // 1
echo rtrim(1.10, '0.'); // 1.1
echo rtrim(1.11, '0.'); // 1.11
echo rtrim(10.01, '0.'); // 10.01
The only edge case you have to watch out for here is if the number is 0 you will end up with an empty string.
Storing age as a varchar will lead to unexpected behaviour for instance when you ORDER BY age in a query.
Use the right types that map to your data.
ON displaying numbers with/without decimal places, use your application language (PHP) to perform this function.
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.
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)
I cannot insert the value "-1" into database, the table set the field is int(10).
I don't know what the problem is. Could you help me. thank you.
$sql2="INSERT INTO attendance_count(username,date,count_time,appendix)VALUES('$applicant','$date1','-1','$altext')";
mysql_query($sql2);
don't put single quote since its an int.
Make sure the column isn't UNSIGNED
the documentation is saying it won't store a literal "-" character,
which means it's probably now doing what the other signed INTEGER
fields have always done and it's storing a sign bit to denote negative
numbers instead.
You're still seeing a minus sign preceding the number because it's
being generated by MySQL as a result of that sign bit.
If you don't understand the sign bit, you can consider how a signed
byte can store numbers from -128 to 127, while an unsigned byte can
store numbers from 0 to 255. That's because one of the 8 bits in a
signed number is being used to store +/- (1 is negative, 0 is
positive), while the remaining bits offer numbers up to 2^7 (-128 or
127).
So, for example, if the bits 1111 had a sign bit they would equal -7
(negative+4+2+1), but if they were unsigned they'd equal 15 (8+4+2+1).
It's still the same amount of bits being stored.
You may wonder why the negative bound in a signed number can use the
8th bit, while the positive bound is limited to the sum of the 7 bits
(1 less than the 8th bit). This is because 10000000 is considered to
be both negative and the 8th bit simultaneously, because its
representation of -0 otherwise is redundant with 00000000 which
represents 0. There's no distinction between negative and positive
zero, so a negative most significant bit is always the value of that
bit itself (but negative).
the column where youre entering the value -1 should be SIGNED
INT(SIGNED) values can be a minimum of-2147483648 to a maximum of 2147483647
INT(UNSIGNED) values can be a minimum of 0 to a maximum of 4294967295
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);