I need to create a good/neutral/bad field. which one would be the more understandable/correct way.
A binary field with null (1=good, null=neutral, 0=bad)
An int (1=good, 2=neutral, 3=bad)
An enum (good, neutral, bad)
Any other
It's only and informative field and I will not need to search by this.
NULL values should be reserved for either:
unknown values; or
not-applicable values;
neither of which is the case here.
I would simply store a CHAR value myself, one of the set {'G','N','B'}. That's probably the easiest solution and takes up little space while still providing mnemonic value (easily converting 'G' to 'Good' for example).
If you're less concerned about space, then you could even store them as varchar(7) or equivalent and store the actual values {'Good','Neutral','Bad'} so that no translation at all would be needed in your select statements (assuming those are the actual values you will be printing).
In Mysql you ought to be using an enum type. You can pick any names you like without worrying about space, because Mysql stores the data as a short integer. See 10.4.4. The ENUM Type in the documentation.
Related
My mysql version is 5.7.14
I have 1 table with two column
1). price_val_float with float data type
2). price_val_double with double data type
Table structure
CREATE TABLE test (
price_val_float FLOAT(6,2),
price_val_double DOUBLE(6,2)
);
Same value in both column
INSERT INTO test VALUES
(78.59, 78.59),
(78.60, 78.60),
(78.61, 78.61);
Now I set one variable as follow
SET #priceValue=78.6;
Now I want to get all record from test table where price_val_float >= #priceValue;
SELECT price_val_float FROM test WHERE price_val_float>= #priceValue;
above query return only 78.61
But if I run same query of price_val_double column
SELECT price_val_double FROM test WHERE price_val_double>= #priceValue;
This return
78.60
78.61
I am not getting why mysql return different result as only data type is different.
Does anyone knows about this ?
Here is Fiddle for testing
Thanks in advance.
This might sound strange to say but this is because decimal numbers are approximates values. This is an issue across all programming due to the nature of storing large numbers. Even the mysql documentation calls these "approximate" values:
https://dev.mysql.com/doc/refman/5.5/en/floating-point-types.html
For example: MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
This is explained in the mysql documentation here:
https://dev.mysql.com/doc/refman/5.5/en/problems-with-float.html
Or as an additional case explained in Python here:
https://docs.python.org/2/tutorial/floatingpoint.html
The way to get around this is identify the precision you want and store the value as an integer.
Float is a single precision and Double is for double precision that why your getting the difference.
This is happening because the difference between the numbers shows up around the tenth decimal or so, depending on factors such as computer architecture or the compiler version or optimization level. For example, different CPUs may evaluate floating-point numbers differently.
You need to use DECIMAL data type for more accurate results. Also check this for more details
That is because Float point values are not stored as exact values. If you need exact value you can use Decimal data type. You can read about it here
I've got a column for storing float data, i.e.
1.1
11.60
4.23
Unfortunately, 11.60 gets stored as 11.6. I need it to have that extra zero. Do I have to change my datatype to varchar? What's the best way to handle this?
It sounds from the comments that you're storing a product code, so float isn't a good choice for a datatype, as you suggest. Indeed it's not a rendering issue, but we'd misconstrued it from your initial choice of float (thinking you indeed were storing something like money or true decimal).
Go with varchar, as you suspected, as it really is a string value.
Here's how you can do that:
create a new column of type varchar(100) or whatever length is suitable for you
copy the values into the new column from your float column
ALTER TABLE MyTable ADD MyNewColumn VARCHAR(100);
UPDATE MyTable
SET MyNewColumn = FORMAT(MyFloatColumn, 2);
This is a rendering issue, not a data issue. To "solve" it, apply mysql's FORMAT function to your value as you select it:
select FORMAT(my_float_column, 2)
from my_table;
The 2 is the number of decimal places. It will handle (almost) any number of digits to the left of the decimal place.
Can anybody give me an example when to use
allow null
default 0
default '' and empty string.
In which situations should use these different configurations?
In general, avoid NULLs. NULL tends to require extra coding effort. Treatment for NULL versus empty string varies by RDBMS. Sorting of NULL within a set varies by RDBMS.
That said, you may wish to:
Use NULLs on foreign key columns when the related row is optional.
Use NULLs when you want values to be eliminated from aggregate operations. For example, if you have an "age" column, but don't require this information for all records, you would still be able to get meaningful information from: SELECT AVG(age) FROM mytable
Use NULLs when you need ternary logic.
1.A NULL value represents the absence of a value for a record in a field (others softwares call it also a missing value).
2.An empty value is a "field-formatted" value with no significant data in it.
3.NULL isn't allocated any memory, the string with NUll value is just a pointer which is pointing to nowhere in memory. however, Empty IS allocated to a memory location, although the value stored in the memory is "".
4.Null has no bounds, it can be used for string, integer, date, etc. fields in a database. Empty string is just regarding a string; it's a string like 'asdfasdf' is, but is just has no length. If you have no value for a field, use null, not an empty string.
5.Null is the database's determination of an absense of a value logically, so to speak. You can query like: where FIELD_NAME is NULL
I haven't used CHAR much in the past as I seemed to use VARCHAR too much; I'm trying to use CHAR when appropriate lately & from what I understand you use it when the data is all the same length in that certain column (else it is padded with spaces).
Because all the data is supposed to be the same length I was wondering can a CHAR field be NULL or an empty string? Such for cases when that specific field doesn't have a value whilst others do.
The answer to your question(s) is Yes.
Yes, the CHAR type can be NULLable. I believe every column type can allow for NULL.
Yes, the CHAR type can be an empty string. The DB will not see an empty string as any different from any other string. I wouldn't suggest ever using empty string though because, in almost every case, an empty string (lack of ANY characters) is trying to represent a lack of data, which is what NULL is for.
If you want to know more specific details around the difference of CHAR vs. VARCHAR in MySQL specifically...
MySQL 5.0 Reference - The CHAR and VARCHAR Types
Yes, both NULL and empty string can be used. The data doesn't have to be the same length in the column, as you noted, anything smaller is just padded with spaces to fill the column.
I would like to store a user status in the database, so, I will use a char to store the status, for example, "active", "inactive", "close". I will use "a", "i", "c" to represent these status. But it is non-sense to store a varchar in database? should I use a char type or set?
**the database in mysql.
You may want to consider using an int or an enum instead. If you do want a char type, CHAR(1) NOT NULL should be fine. With an enum, it would be:
status ENUM('active', 'inactive', 'close')
With an int:
status tinyint
Using an int is a good option, but document the values well.
One thing to beware of is that adding a new value to an enum requires rewriting the entire table. I generally recommend storing CHAR or VARCHAR. One can add a FK reference to a table of legal values if you want an other aspect of enums, that of requiring the value to be a listed one. Then the 'almost enum' can be extended by adding another value to the FK'ed table.