I'm a music reviewer and I want to build my website.
I've built a database in mysql with a column for the ratings.
Here are the possibilities : 10, 9.5, 9, 8.5, 8, 7.5 ... 1, 0.5, and 0
What kind of colum can I use, for now I choose DECIMAL with value of : 3,1
The problem is that when I enter 9, it returns 9.0 ... Is there a way to store Whole and Decimal numbers in a column?
For formatting the numbers for display, you would do that kind of processing in whatever language you were parsing the mysql results in. In PHP, for example, you would simply cast to a float and print it.
$string = '9.0000000';
echo (float)$string;
This would print '9'.
Store them as a decimal but as a part of 100. 9.9 would be 99. Then use php to divide by 10 and cast it to a double.
You can cast to double while dividing by adding a decimal and 0.
Result / 10.0
You are conflating the value with the representation. If you are not doing arithmetic on the values (just comparing them), then you might consider storing them as strings.
Alternatively, when selecting them for printing them out, you can format the values as you wish:
select (case when rating % 1 = 0 then format(rating, 0)
else format(rating, 1)
end)
Related
I have a question about a query that I'm running on a MySQL Server (v5.5.50-0+deb8u1).
SELECT 12 - (SELECT qty FROM Table WHERE id = 5213) AS Amount
so Amount value is 12 - 8,5500000000000007 = 3.4499999999999993
But if I run the query:
SELECT qty FROM Table WHERE id = 5213
it returns 8.55 that is the correct number written in the record, so I was expecting that the first querty returned 3.45.
The "qty" column in the table "Table" is a DOUBLE.
How is it possibile? How can I get the right answer from the query?
thanks in advance
Well that's just the way floating numbers are.
Floating-point numbers sometimes cause confusion because they are
approximate and not stored as exact values. A floating-point value as
written in an SQL statement may not be the same as the value
represented internally.
This statement holds true for many programming languages as well. Some numbers don't even have an exact representation. Here's something from the python manual
The problem is easier to understand at first in base 10. Consider the
fraction 1/3. You can approximate that as a base 10 fraction:
0.3 or, better,
0.33 or, better,
0.333 and so on. No matter how many digits you’re willing to write down, the result will never be exactly 1/3, but will be an
increasingly better approximation of 1/3.
In the same way, no matter how many base 2 digits you’re willing to
use, the decimal value 0.1 cannot be represented exactly as a base 2
fraction. In base 2, 1/10 is the infinitely repeating fraction
So in short generally doing is float1 = float2 type of comparison is a bad idea but everyone keeps forgetting it.
You can define 'qty' column as decimal(10,2)
I have a float column and I'm trying to save the value 1000000. It automatically turns it to 1e+06. How can I fix it?
To have the value returned formatted as 1000000, you can simply add integer zero to the column in the SELECT list.
SELECT mycol+0 AS mycol FROM mytable
MySQL is storing the value IEEE floating point format. (One bit for sign, a certain number of bits for the exponent, and a certain number of bits for the mantissa. This isn't really a MySQL thing, it's the standard representation for floating point values.)
As far as what's being returned, that's an issue with converting that value into string representation.
A floating point number has a large range of values. To represent the maximum value of a float (3.402823e+38) as a decimal value, that would require 38 decimal digits. The seven left most digits of the value are significant, but we'd need to add another 32 zeros/digits to indicate the position of the decimal point.
So, returning a string representation of scientific notation is a reasonable approach to returning a representation of the value.
Those two things are equivalent:
1e+06
= 1 * 10^6
= 1 * 1,000,000
= 1,000,000
It's called scientific notation (see here). mySQL uses it to display huge/tiny values, especially approximate values (see here).
You can use DOUBLE(8, 3) where 8 is the total no. of digits excluding the decimal point, and 3 is the no. of digits to follow the decimal.
I am storing monetary values, and I read that FLOAT has internal rounding problems (although I can't say I ever noticed any problems) and that it is better to use DECIMAL.
So I have been using DECIMAL but when I try to set the value to 1 it is stored as 0.99. I will be using that value in JavaScript at some point, and I know that my JS calculations will be wrong because it is 0.99 not 1.00.
Why is it doing that and should I just use FLOAT?
You need DECIMAL(4, 2) by the looks of things. DECIMAL(2, 2) only allows a range of -0.99 to 0.99
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. so in your case you have not defined the column to allow any integer part at all.
I am calculating percentages. One example is coming down to 38589/38400
So the percentage is 100*(38589/38400) which equals something like 100.4921875, but the result shows up as 100.
How can I get it to be displayed with x number of decimals?
Similarly, will the same work if i'd like 2 to be displayed as 2.000000?
Thanks!
You can cast it to a specific data type, which preserves the data type as well as rounding to a certain precision
select cast(100*(38589/38400) as decimal(10,4))
FYI
select 100*(38589/38400)
# returns 100.4922, not 100 for me
select cast(2 as decimal(20,6))
# output : 2.000000
With regards to your number formatting have you looked at the format function:
mysql> SELECT FORMAT(12332.123456, 4);
-> '12,332.1235'
mysql> SELECT FORMAT(12332.1,4);
-> '12,332.1000'
mysql> SELECT FORMAT(12332.2,0);
-> '12,332'
so to get 2.000000 from 2 do:
SELECT FORMAT(2,6);
Also, according to mySQL's documentation regarding division:
In division performed with /, the
scale of the result when using two
exact-value operands is the scale of
the first operand plus the value of
the div_precision_increment system
variable (which is 4 by default). For
example, the result of the expression
5.05 / 0.014 has a scale of six decimal places (360.714286).
These rules are applied for each
operation, such that nested
calculations imply the precision of
each component. Hence, (14620 /
9432456) / (24250 / 9432456), resolves
first to (0.0014) / (0.0026), with the
final result having 8 decimal places
(0.60288653).
This would lead me to agree with #Cyberwiki regarding the result you would see from your division.
You need to convert one of the types to floating point:
SELECT 100.0 * ((338589 * 1.0)/38400) ...
With regards to the reason why the result shows 100 instead of 100.4921875 is maybe related to the type of the corresponding column assuming that you store the result in a table column. Make sure that the type of that column is Double.
If you'd like 2 to be displayed as 2.000000, just multiply it by 1.0 as follows:
(select (100*(38589/38400*1.0))
and the output will show: 100.49219
Database newbie here. I'm setting up a mysql table. One of the fields will accept a value in increment of a 0.5. e.g. 0.5, 1.0, 1.5, 2.0, .... 200.5, etc.
I've tried int but it doesn't capture the decimals.
`value` int(10),
What would be the smallest type that can accommodate this value, considering it's only a single decimal.
I also was considering that because the decimal will always be 0.5 if at all, I could store it in a separate boolean field? So I would have 2 fields instead. Is this a stupid or somewhat over complicated idea? I don't know if it really saves me any memory, and it might get slower now that I'm accessing 2 fields instead of 1
`value` int(10),
`half` bool, //or something similar to boolean
What are your suggestions guys? Is the first option better, and what's the smallest data type in that case that would get me the 0.5?
You'll want to look at the DECIMAL(P,S) type.
For that, P is the precision and S is the scale. You can think of P as how many digits there are in total (both before and after the decimal point), and S as how many of the digits are after the decimal point.
So for instance, to store from -999.99 to 999.99, you'd need 5 digits of precision and a scale of 2, therefore you'd use DECIMAL(5, 2).
In your case, you'd need a DECIMAL(n, 1), where n is how many digits you need before the decimal point + 1 for the decimal.
You can use
DECIMAL(N,1)
Where N is the precision that represents the max number of significant digits that can be stored.
Apart from using DECIMAL, you could store the tenfold of the value in an INT column (which I would think could be more efficient.)
0.5 => 5
201.5 => 2015
etc.