I'm trying to make a MySQL query that returns rows where (col_a+col_b-col_c+col_d) != col_e, where all of the columns are decimal and default to null. There is one row that I know of that meets these requirements, but when I ran the query with the above logic as the WHERE clause, the row didn't show up. I noticed that col_c was null, instead of a numerical value, and after changing it to 0 the row showed up when I ran the query.
Why did this happen? I have always assumed that null was interpreted as 0 in an instance such as the above?
NULL (as far as my interpretation goes) is unrepresentable data. The only appropriate tests for null are IS NULL, IS NOT NULL, and several functions made specifically to handle NULL values: http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html
You could say - IFNULL(col_c, 0)+col_d (COALESCE will work identically in this case).
More information on working with NULLs: http://dev.mysql.com/doc/refman/5.0/en/problems-with-null.html
Nate, NULL is NULL. MySQL is not going to do the type conversion automatically for you. A way around for that is change the table's column DEFAULT to 0. Or use a function IFNULL(col_c, 0) into your expression.
;-)
Anytime you do a mathematical calculation where one or more of the values might be NULL you need to account for it in the formula by using a numerical identity operation, since any calculation containing a NULL will have a result of NULL. Here are some common cases:
Addition or Subtraction use 0
ifnull(col1,0)+ifnull(col2,0)
ifnull(col1,0)-ifnull(col2,0)
Multiplication, Division, Exponents, or Modulus use 1
ifnull(col1,1)*ifnull(col2,1)
ifnull(col1,1)/ifnull(col2,1)
power(ifnull(col1,1),ifnull(col2,1))
mod(ifnull(col1,1),ifnull(col2,1))
Related
This is part of my query
(t.as_num_responded-sqrt(t.as_num_responded))/t.as_num_subjects as 'RF score'
where t is my database, the problem arrives when I try to use the coalesce function, it doesn't work on it, to replace the NULL to 0.
coalesce(t.as_num_responded-sqrt(t.as_num_responded))/t.as_num_subjects) as 'RF score'
Not sure if I'm using the coalesce wrong or if it is because the new column 'RF score' is created as a varchar, I need the values as floats with two decimals. Please, any help will be very helpful. Thank you.
My comment is pretty much an answer I guess.
Coalesce goes through a list of values and returns the first non-null value in doing so. Unfortunately you are giving it one arguement, and if that value is null...it goes to the next, finds nothing, and returns null.
2 ways of fixing...
coalesce (yourfunction,0)
where yourfunction is the (t.as_num_responded-sqrt(t.as_num_responded))/t.as_num_subjects) line
This will return 0 when your function is null.
Isnull(yourfunction,0)
Isnull is a more simple version...instead of taking a list of fields, it just does one field and replaces nulls with the second arguement of the isnull function.
I've a simple table in my Mysql database.
The table T has a column A, of type tinyint unsigned, and lenght 1. I use that column to store some boolean values.
When I try to do some simple arithmetic stuff, I get very strange results, for example:
SELECT A - 1 FROM T
returns 0, correctly, if the value of A is 1, but returns 18446744073709551615 (I think ifs 2^64 - 1) if A is 0.
My question is... why, and how can I fix that?
EDIT: declaring A as Signed solves the problem... But I can't understand why. I get that probably if a column is unsigned, -1 is represented as a very large number (2^n - 1), but if the result is of the same type of the column you select, why a 64 bit number?
Unsigned ints cannot hold a negative value
If you try and subtract 1 from 0 it loops back round to the largest value it can have
http://en.wikipedia.org/wiki/Signedness
Not sure if that makes much sense but let me know if still stuck and will try to explain better!
Unsigned means the variable cannot deal with negative numbers, even if it is involved as part of a calculation in SQL.
Try signed.
In my DB, I have currently float data. All column are set to be NULLABLE and when value is missing I put there NULL.
My DB is too big and if I know, that values are in range 0 - 100 they can be rounded to 1 decimal place. So using float is overhead and I am thinking of use smallint (multiply every float by 10 and store it as rounded number). Now, what about NULL values.
I have two options:
still use NULL
use some "out of bounds" value, like 9999, to represent NULL (and also make this value default, when nothing is set for column). However, in my queries, I need to do this:
SELECT AVG(NULLIF(data, 9999)) AS data, ....
(When I use NULL, i can just use AVG(data), while NULL values are not computed..)
What is better to use. Or is there a better technique?
Why would you try to "roll your own" NULL functionality if it already exists? As you describe it, your usage of NULLs is correct and perfectly valid. I don't see any advantage you'd gain by using a magic number as an artificial NULL replacement; you'd just introduce the possibility for errors.
TL;DR:
Use NULL.
Why would you use valid data to represent NULL if you have the opton to actually use NULL itself?
I do not see any benifit
The NULL value takes the exact same space than a value on a fixed field (float, int...). You can't optimize the space use by not using NULL, or whatever. Sorry :)
When you are using NULL means that you set this column as 'nothing', in the second case you give your column a value that represents the NULL.
So in first your don't have set your column and at second you set a value that shows it is NULL.It depends on what you want to do. If you want to be commitment in your db on that column use the second, else if you want just to be empty unless you fill it use NULL .
whenever we create our table in mysql database then a option of null checkbox is present there. and if click it then also it takes the null value and if it remains unchecked then also it takes null values. What is the meaning of that?
NULL is used to represent "no value" and allow that to be distinguished between 1 and 0, true or false, or an empty string versus a string with content. It's similar to nil in Ruby, null in JavaScript or NULL in PHP.
If you define a column as NOT NULL then it won't allow an INSERT without a value for that column being specified. If you have a DEFAULT then this will be applied automatically. If you use an ORM it may fill it in for you with a safe, minimal default.
Columns that can be NULL require an almost insignificant amount of additional storage per row, one bit, to hold the NULL or NOT NULL flag.
Remember that NULL in MySQL is unusual in that it is not greater than, less than, or equal to any other value. This is why IS NULL and IS NOT NULL are required for logical comparisons.
The checkbox probably sets the default value to null. There may also be a box that specifies whether or not the field accepts null values. Null basically means Empty or Nothing (in VB).
Null is basically "no value". If you allow nulls, you need to ensure that your code is able to handle that column not containing a value. Another approach is a defined "empty" value for each column (e.g. 0 for an integer). This can sometimes be less effort than handling a null value.
As noted by HLGEM below: I'm not trying to say 0 is equivalent to null. Consider:
DB with "StockOnHand" column.
0 means you know there is no stock on hand.
Null really means unknown (you man have stock, you may not)
Depending on the application, perhaps you decide to treat "unknown" the same as "no stock" - in this case you could use "no nulls" and just have a 0 value.
According to the manual:
The NULL value means "no data." NULL can be written in any lettercase. A synonym is \N (case sensitive).
NOT NULL would mean the opposite of NULL, or not no data. Since some columns can be NULL, you use WHERE col IS NOT NULL to find values that are not "empty."
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