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
Related
I am running a query on a db table which is returning one record when I expect it to return no records.
SELECT yeargroupID FROM tbl_yeargroup WHERE yeargroup='S' AND schoolID=2.
The yeargroup field is a tinyint field. Thefore the WHERE clause is looking the letter 'S' in the numeric field, so should not find anything. Yet it returns the record with the yeargroup = 0, and yeargroupID=17 (the bottom record in the table)
I'm confused as to why it is returning this record and how to avoid it.
Thanks
This logic, as you have pointed out, is comparing a number and a string:
WHERE yeargroup = 'S'
Handling such situations is an important part of most SQL compilers, and it is well documented. The solution is to implicitly convert values to "conforming" types. This is sad. My preference would be for the compiler to generate an error and force the user to use correct types. I find that implicit conversion creates more problems than it solves.
In any case, the rules in this case are pretty simple. The string is converted to an integer. But, how is a string with no digits converted? Well, the rule in MySQL is that the leading digits are converted to a number. And if there are none, the value is 0. So, this turns into:
where yeargroup = 0
You can see the results more clearly if you run:
select 'S', 'S' + 0
Note that most databases would return an error in this case (a type conversion error). But even those would accept the string if it looked like a number, so this would be allowed:
where yeargroup = '5'
What is the proper solution? Never mix types. Do not construct queries by munging constant values. Instead, queries from an application should always be using parameters.
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 .
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))
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."
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.