92

How are the NULL and Empty Varchar values stored in SQL Server. And in case I have no user entry for a string field on my UI, should I store a NULL or a '' ?

Akram Shahda
  • 14,655
  • 4
  • 45
  • 65
  • Related: [SQL: empty string vs NULL value](http://programmers.stackexchange.com/q/32578/85530) – Edward Brey Jan 24 '14 at 02:33
  • If you go the empty string route, please make sure it's empty! Trim out any spaces! Trim it twice if necessary to make sure it's empty! Please. – Airn5475 Aug 16 '18 at 20:21

9 Answers9

82

There's a nice article here which discusses this point. Key things to take away are that there is no difference in table size, however some users prefer to use an empty string as it can make queries easier as there is not a NULL check to do. You just check if the string is empty. Another thing to note is what NULL means in the context of a relational database. It means that the pointer to the character field is set to 0x00 in the row's header, therefore no data to access.

Update There's a detailed article here which talks about what is actually happening on a row basis

Each row has a null bitmap for columns that allow nulls. If the row in that column is null then a bit in the bitmap is 1 else it's 0.

For variable size datatypes the acctual size is 0 bytes.

For fixed size datatype the acctual size is the default datatype size in bytes set to default value (0 for numbers, '' for chars).

the result of DBCC PAGE shows that both NULL and empty strings both take up zero bytes.

openshac
  • 4,966
  • 5
  • 46
  • 77
  • 2
    That's not really a discussion of the point. It's really just someone expressing their opinion with nothing to back it up. The only point they've raised is the space requirements are the same and this does not support either method. – MikeKulls Jul 04 '12 at 07:13
  • Updated to provide more detail on what is happening on a row/column basis. – openshac Jul 04 '12 at 11:07
  • 13
    "Another thing to note is what NULL means in the context of a relational database. It means that the pointer to the character field is set to 0x00 in the row's header, therefore no data to access." NULL does not mean that in the context of a relational database. It only means that in one particular vendor's implementation of a relational database. – Thanatos Oct 30 '12 at 22:39
  • 7
    The first link is broken. – Spivonious Jan 14 '16 at 20:10
  • 1
    @Spivonious - link is now fixed. – openshac Sep 04 '20 at 06:04
  • I disagree with the 1st article's premise, that it's better to use '' than NULL. NULL is shown as NULL in SELECT queries, whereas '' is shown as <>. I'd rather see "something" than "nothing", to be sure it's a NULL – Fandango68 Sep 08 '21 at 01:45
  • In case if you need to use unique constraints, use empty strings. Due to the fact that `NULL` != `NULL`, unique constraints applied to nullable fields will allow inserting similar data rows, like `1,2,NULL` and `1,2,NULL`. – Prisacari Dmitrii Dec 02 '21 at 10:32
53

Be careful with nulls and checking for inequality in sql server.

For example

select * from foo where bla <> 'something' 

will NOT return records where bla is null. Even though logically it should.

So the right way to check would be

select * from foo where isnull(bla,'') <> 'something' 

Which of course people often forget and then get weird bugs.

Vagif Verdi
  • 4,816
  • 1
  • 26
  • 31
  • 11
    It's hard enough having to accept that "null = null" returns false, but having "null <> 'something'" also returning false just feels downright cruel. – MikeTeeVee Oct 07 '11 at 19:58
  • 17
    @MikeTeeVee: It's not `FALSE`, in either case. It's `UNKNOWN` and doesn't pass the condition (only `TRUE` result passes). – ypercubeᵀᴹ Apr 11 '12 at 19:16
  • 3
    The query above can be optimized a bit and it will be a bit faster. Instead of doing `select * from foo where isnull(bla,'') <> 'something'`, you can do `select * from foo where (bla <> 'something') or (bla is null)` – Nicolas Nov 20 '15 at 10:51
  • but that condition would make an empty string and `NULL` the same – Jimmy T. Jul 03 '21 at 21:35
19

The conceptual differences between NULL and "empty-string" are real and very important in database design, but often misunderstood and improperly applied - here's a short description of the two:

NULL - means that we do NOT know what the value is, it may exist, but it may not exist, we just don't know.

Empty-String - means we know what the value is and that it is nothing.

Here's a simple example: Suppose you have a table with people's names including separate columns for first_name, middle_name, and last_name. In the scenario where first_name = 'John', last_name = 'Doe', and middle_name IS NULL, it means that we do not know what the middle name is, or if it even exists. Change that scenario such that middle_name = '' (i.e. empty-string), and it now means that we know that there is no middle name.

I once heard a SQL Server instructor promote making every character type column in a database required, and then assigning a DEFAULT VALUE to each of either '' (empty-string), or 'unknown'. In stating this, the instructor demonstrated he did not have a clear understanding of the difference between NULLs and empty-strings. Admittedly, the differences can seem confusing, but for me the above example helps to clarify the difference. Also, it is important to understand the difference when writing SQL code, and properly handle for NULLs as well as empty-strings.

Gordon J
  • 215
  • 2
  • 4
  • 14
    I would like to point out that this is not universally objective opinion. – industryworker3595112 Aug 01 '17 at 12:15
  • 3
    You argue here that NULL means "unknown" and should not mean "nothing"/"not applicable". But what about other datatypes? If we have table CONTRACTS, with column, "maturity_date" of type DATE. What if we have contract, which does not have maturity date (e.g. deposit until demanded). In such cases quite accepted way to deal with it is to leave "maturity_date=NULL". (i.e. for every other datatype, NULL is appropriate in case of "nothing"/"not applicable") (my point: null vs empty-string vs special-value is just a matter of agreement convention) – industryworker3595112 Aug 01 '17 at 12:28
  • yeah, I have to agree this is more a single implementation of the two. It is reasonable, but so are other implementations. – Mike M Sep 07 '17 at 04:40
17

An empty string is a string with zero length or no character. Null is absence of data.

Sorter
  • 9,704
  • 6
  • 64
  • 74
Kent
  • 2,952
  • 2
  • 25
  • 42
  • 4
    That is one interpretaion of NULL. In certain contexts, it is clearly the correct one. But SQL is not consistent when it comes to NULL, so there are contexts where NULL means unknown. For example, "NULL != 'x'" returns NULL because in this context NULL means unknown. If it was an absence, it would make no sense, because 'x' is not equal to an absence. – Federico Razzoli Oct 31 '20 at 03:56
  • Why are we comparing NULL and '' in terms of space taken? Who cares!? NULL is no data, whereas '' is a ZERO length string. – Fandango68 Sep 08 '21 at 01:47
  • 2
    @Fandango68 For storage optimization: some of us have tables with tens-of-billions of rows in them, and if one particular representation (one of `NULL` or `''` or `N''`) uses less disk-space or is quicker to process than the others _without otherwise compromising our database design_ then that can represent a considerable saving in operational expenses. – Dai Aug 10 '22 at 12:24
  • @Dai wow learn something new every day. Thanks – Fandango68 Aug 10 '22 at 23:58
3

NULL values are stored separately in a special bitmap space for all the columns.

If you do not distinguish between NULL and '' in your application, then I would recommend you to store '' in your tables (unless the string column is a foreign key, in which case it would probably be better to prohibit the column from storing empty strings and allow the NULLs, if that is compatible with the logic of your application).

Andriy M
  • 76,112
  • 17
  • 94
  • 154
1

NULL is a non value, like undefined. '' is a empty string with 0 characters.
The value of a string in database depends of your value in your UI, but generally, it's an empty string '' if you specify the parameter in your query or stored procedure.

Michaël
  • 6,676
  • 3
  • 36
  • 55
1

if it's not a foreign key field, not using empty strings could save you some trouble. only allow nulls if you'll take null to mean something different than an empty string. for example if you have a password field, a null value could indicate that a new user has not created his password yet while an empty varchar could indicate a blank password. for a field like "address2" allowing nulls can only make life difficult. things to watch out for include null references and unexpected results of = and <> operators mentioned by Vagif Verdi, and watching out for these things is often unnecessary programmer overhead.

edit: if performance is an issue see this related question: Nullable vs. non-null varchar data types - which is faster for queries?

Community
  • 1
  • 1
Alexander Taylor
  • 16,574
  • 14
  • 62
  • 83
0

In terms of having something tell you, whether a value in a VARCHAR column has something or nothing, I've written a function which I use to decide for me.

CREATE FUNCTION [dbo].[ISNULLEMPTY](@X VARCHAR(MAX))
RETURNS BIT AS
BEGIN
    DECLARE @result AS BIT
    IF @X IS NOT NULL AND LEN(@X) > 0
        SET @result = 0
    ELSE
        SET @result = 1
        
    RETURN @result
END

Now there is no doubt.

Fandango68
  • 4,461
  • 4
  • 39
  • 74
-2

How are the "NULL" and "empty varchar" values stored in SQL Server. Why would you want to know that? Or in other words, if you knew the answer, how would you use that information?

And in case I have no user entry for a string field on my UI, should I store a NULL or a ''? It depends on the nature of your field. Ask yourself whether the empty string is a valid value for your field.

If it is (for example, house name in an address) then that might be what you want to store (depending on whether or not you know that the address has no house name).

If it's not (for example, a person's name), then you should store a null, because people don't have blank names (in any culture, so far as I know).