I am confusing a lot, about, Empty, Null and not Null database fields value.
I have a tab where is several fields are containing Empty/blank data some of them containing NULL data, and containing actual data.
I am confuse what the difference between Epmyt/Blank and Null data.
Please help me.
Thanks
Ravik
Empty or blank usually refers to an empty string value, length = 0 characters. Null means no value, not even an empty one.
NULL is a database indicator that specifies that the value in the database is missing or indeterminate. Empty strings are zero-length varchar strings.
They may or may not be the same when you select values. SQL Server Management Studio, for instance, exports NULL values as "NULL" instead of a blank string.
NULLs follow some very basic comparison rules that many find counterintuitive. Any comparison operation -- except for is null -- returns false. In particular, the following two return false:
where NULL = NULL
where NULL <> NULL
This applies to columns that have a NULL value as well So these both return false, when val contains a NULL value:
where val = val
where val <> val
Blank/empty string is just a value for a variable length string that has a length of 0, usually represented as ''. The following does return true:
where '' = ''
where val = val -- given that val is ''
The one complication is that some databases treat NULL values as zero-length strings. Oracle comes to mind. However, this is not ANSI-compliant behavior.
NULL is different from an empty value in that with NULL, you don't know for sure if the value is empty or not. This has real measurable impacts in your database. Here are some examples:
The LEN() of an empty varchar field is 0. The LEN() of a NULL field is still NULL... you don't know how large the field is.
Two empty fields compared to themselves ('' = '') are true. You don't know if two NULL fields are equal or not, so (NULL = NULL) results in NULL.
The COALESCE('', ... ) of an empty field results in the empty field. The COALESCE(NULL, ... ) of a NULL field falls through to the next value.
There are many more examples like this. NULL does not mean empty. NULL means "I don't know."
Related
I am using SQL to compare two columns and return TRUE/FALSE if they are equal.
In some cases, the two columns contain exactly the same string (no spaces or anything) but I am still getting false.
What may the reason for this be?
I am using this code:
CASE WHEN column1 = column2 THEN 0 ELSE 1 END AS [check]
The values are different despite the displayed value.
Using T-SQL, run a query like this to see the exact difference in the underlying raw values:
SELECT
column1
, CAST(column1 AS varbinary(MAX)) AS column1Binary
, column2
, CAST(column2 AS varbinary(MAX)) AS column2Binary
FROM dbo.YourTable;
This will reveal underlying differences like tabs or subtle character differences.
In fact, a likely explanation for what you are seeing is that one/both of the strings has leading and/or trailing whitespace. On SQL Server you may try:
CASE WHEN LTRIM(column1) = LTRIM(column2) THEN 0 ELSE 1 END AS [check]
If the above does not detect the problematical records, then try checking the length:
CASE WHEN LEN(column1) = LEN(column2) THEN 0 ELSE 1 END AS [check2]
Why
select 1 - NULL
returns NULL instead of 1?
It wasn't clearly expected to me.
Null: A value of NULL indicates that the value is unknown. A value of NULL is different from an empty or zero value. No two null values are equal. Comparisons between two null values, or between a NULL and any other value, return unknown because the value of each NULL is unknown.
If you do any arithmetic operations with null the whole expression evaluates to Null. In order to handle null you should use Isnull() or coalesce function like this.
select 1 - isnull(NULL,0) as result
Simply because NULL is not 0.
If it helps, consider NULL as a synonym for "unknown", and then it'll make perfect sense - the result of 1 minus an unknown number can only give an unknown result.
Here are some references on how NULL behaves differently:
NULL can be thought of as UNKNOWN (docs).
Arithmetic operations with NULL result in NULL (wiki).
SUM() operation ignores NULL instead of returning UNKNOWN (docs).
String concatenation with NULL result in NULL (wiki and comment by #Zohar).
Boolean comparisons with NULL use three-value logic (wiki).
Where clauses with NULL should use IS, because boolean comparisons result in UNKNOWN not TRUE (docs).
To determine whether an expression is NULL, use IS NULL or IS NOT NULL instead of comparison operators (such as = or !=). Comparison operators return UNKNOWN when either or both arguments are NULL.
I understand why null + 1 or (1 + null) returns null: null means "unknown value", and if a value is unknown, its successor is unknown as well. The same is true for most other operations involving null.[*]
However, I don't understand why the following happens:
SELECT SUM(someNotNullableIntegerField) FROM someTable WHERE 1=0
This query returns null. Why? There are no unknown values involved here! The WHERE clause returns zero records, and the sum of an empty set of values is 0.[**] Note that the set is not unknown, it is known to be empty.
I know that I can work around this behaviour by using ISNULL or COALESCE, but I'm trying to understand why this behaviour, which appears counter-intuitive to me, was chosen.
Any insights as to why this makes sense?
[*] with some notable exceptions such as null OR true, where obviously true is the right result since the unknown value simply does not matter.
[**] just like the product of an empty set of values is 1. Mathematically speaking, if I were to extend $(Z, +)$ to $(Z union {null}, +)$, the obvious choice for the identity element would still be 0, not null, since x + 0 = x but x + null = null.
The ANSI-SQL-Standard defines the result of the SUM of an empty set as NULL. Why they did this, I cannot tell, but at least the behavior should be consistent across all database engines.
Reference: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt on page 126:
b) If AVG, MAX, MIN, or SUM is specified, then
Case:
i) If TXA is empty, then the result is the null value.
TXA is the operative resultset from the selected column.
When you mean empty table you mean a table with only NULL values, That's why we will get NULL as output for aggregate functions. You can consider this as by design for SQL Server.
Example 1
CREATE TABLE testSUMNulls
(
ID TINYINT
)
GO
INSERT INTO testSUMNulls (ID) VALUES (NULL),(NULL),(NULL),(NULL)
SELECT SUM(ID) FROM testSUMNulls
Example 2
CREATE TABLE testSumEmptyTable
(
ID TINYINT
)
GO
SELECT SUM(ID) Sums FROM testSumEmptyTable
In both the examples you will NULL as output..
IF #insertedValue IS NOT NULL AND #insertedValue > 0
This logic is in a trigger.
The value comes from a deleted or inserted row (doesn't matter).
2 questions :
Do I need to check both conditions? (I want all value > 0, value in db can be nullable)
Does SQL Server check the expression in the order I wrote it ?
1) Actually, no, since if the #insertedValue is NULL, the expression #insertedValue > 0 will evaulate to false. (Actually, as Martin Smith points out in his comment, it will evaluate to a special value "unknown", which when forced to a Boolean result on its own collapses to false - examples: unknown AND true = unknown which is forced to false, unknown OR true = true.) But you're relying on comparison behaviour with NULL values. A single step equivalent method, BTW, would be:
IF ISNULL(#insertedValue, 0) > 0
IMHO, you're better sticking with the explicit NULL check for clarity if nothing else.
2) Since the query will be optimised before execution, there is absolutely no guarantee of order of execution or short circuiting of the AND operator.
Combining the two - if the double check is truly unnecessary, then it will probably be optimised out before execution anyway, but your SQL code will be more maintainable in my view if you make this explicit.
You can use COALESCE => Returns the first nonnull expression among its arguments.
Now you can make the query more flexible, by increasing the column limits and again you need to check the Greater Then Zero condition. Important point to note down here is you have the option to check values in multiple columns.
declare #val int
set #val = COALESCE( null, 1, 10 )
if(#val>0)
select 'fine'
else
select 'not fine'
If not, is there an alternate way to switch through SELECT statements using a CASE or IF/THEN identifier WITHOUT putting the statement in a scalar variable first?
Is there a way to format this without using IS and using an = sign for it to work?
SELECT ID FROM TABLE WHERE ID = Null
No. NULL isn't a value. Think of NULL as a condition, with IS NULL or IS NOT NULL is testing for this condition.
In this example you can test for the actual value, or lack of value represented by a conditon
WHERE
(X IS NULL OR X = #X)
OR
WHERE
(#X IS NULL OR X = #X)
Or test for your definite conditions first:
WHERE
CASE X
WHEN 1 THEN
WHEN 2 THEN
ELSE -- includes NULL
END = ...
Your question is abstract so hard to give a more precise answer.
For example, are you having problems with NOT IN and NULL? If so, use NOT EXISTS.