tags:

views:

1299

answers:

4

I have a form on a website which has a lot of different fields. Some of the fields are optional while some are mandatory. In my DB I have a table which holds all these values, is it better practice to insert a NULL value or an empty string into the DB columns where the user didn't put any data?

+16  A: 

By using NULL you can distinguish between "put no data" and "put empty data".

Some more differences:

  • A LENGTH of NULL is NULL, a LENGTH of an empty string is 0.

  • NULLs are sorted before the empty strings.

  • COUNT(message) will count empty strings but not NULLs

  • You can search for an empty string using a bound variable but not for a NULL. This query:

    SELECT  *
    FROM    mytable 
    WHERE   mytext = ?
    

    will never match a NULL in mytext, whatever value you pass from the client. To match NULLs, you'll have to use other query:

    SELECT  *
    FROM    mytable 
    WHERE   mytext IS NULL
    
Quassnoi
+1 NULL *always* NULL
annakata
but which one you think is faster? 0 or NULL or ""
aadravid
@aadravid: no difference.
Quassnoi
+1  A: 

I don't know what best practice would be here, but I would generally err in favor of the null unless you want null to mean something different from empty-string, and the user's input matches your empty-string definition.

Note that I'm saying YOU need to define how you want them to be different. Sometimes it makes sense to have them different, sometimes it doesn't. If not, just pick one and stick with it. Like I said, I tend to favor the NULL most of the time.

Oh, and bear in mind that if the column is null, the record is less likely to appear in practically any query that selects (has a where clause, in SQL terms) based off of that column, unless the selection is for a null column of course.

Platinum Azure
...And now that I see the answer above me, I think it's safe to say that the usual differentiation you would care about is no data versus empty data. :-)
Platinum Azure
+2  A: 

One thing to consider, if you ever plan on switching databases, is that Oracle does not support empty strings. They are converted to NULL automatically and you can't query for them using clauses like WHERE somefield = '' .

Matt Solnit
This sounded incredibly fishy to me, even on your link, so I tried it. Null field, set to '', oracle ignores it. Reports length as null rather than 0. That's just so wrong. There's got to be some way around this. Think I'll post this as another question.
Steve B.
`Steve B.`: see this question: http://stackoverflow.com/questions/1171196/difference-between-varchar-and-varchar2
Quassnoi
Thanks for the reference, though I still don't understand the reasoning.Posted as http://stackoverflow.com/questions/1268177/oracle-not-distinguishing-between-nulls-and-empty-strings
Steve B.
A: 

One thing to keep in mind is that NULL might make your codepaths much more difficult. In pytohn for example most database adapters / ORMs map NULL to None.

So things like:

print "Hello, %(title)s %(firstname) %(lastname)!" % databaserow

might result in "Hello, None Joe Doe!" To avoid it you need something like this code:

if databaserow.title:
    print "Hello, %(title)s %(firstname) %(lastname)!" % databaserow
else:
    print "Hello, %(firstname) %(lastname)!" % databaserow

Which can make things much more complex.

mdorseif
In my opinion abusing your database to "fix" errors in your code or the framework is a (very) bad coding practice. When there is no data you should just insert NULL and be consistent in using that. Otherwise you must use statements like: if(myString == null || myString = ""). When an object is not set or defined in your code you are also using NULL instead of some kind of "placeholder" (which an empty string is in my opinion).
Gertjan
Depends very much on your Language of choice. In Python "if not myString:" tests for None and "". Probably mainly a cultural issues. The Java Guys "bad practice" is the dynamic person's elegance.
mdorseif