NULL vs Empty when dealing with user input

Question

Yes, another NULL vs empty string question.

I agree with the idea that NULL means not set, while empty string means "a value that is empty". Here's my problem: If the default value for a column is NULL, how do I allow the user to enter that NULL.

Let's say a new user is created on a system. There is a first and last name field; last name is required while first name is not. When creating the user, the person will see 2 text inputs, one for first and one for last. The person chooses to only enter the last name. The first name is technically not set. During the insert I check the length of each field, setting all fields that are empty to NULL.

When looking at the database, I see that the first name is not set. The question that immediately comes to mind is that maybe they never saw the first name field (ie, because of an error). But this is not the case; they left if blank.

So, my question is, how do you decide when a field should be set to NULL or an empty string when receiving user input? How do you know that the user wants the field to be not set without detecting focus or if they deleted a value...or...or...?

Related Question: Should I use NULL or an empty string to represent no data in table column?

Solution 1

I almost never use NULL when referring to actual data. When used for foreign keys, I would say that NULL is valid, but it is almost never valid for user entered data. The one exception that would probably come up quite regularly is for dates that don't exist, such as an employee database with a "termination_date" field. In that case, all current employees should have a value of NULL in that field. As for getting them to actually enter a null value, for the values that truly require a null value, I would put a checkbox next to the input field so that the user can check it on and off to see the corresponding value to null (or in a more user friendly manner, none). When enabling the checkbox to set the field to null, the corresponding text box should be disabled, and if a null value is already associated, it should start out as disabled, and only become enabled once the user unchecks the null checkbox.

Solution 2

I'll break the pattern, and say that I would always use NULL for zero-length strings, for the following reasons.

1. If you start fine-slicing the implications of blanks, then you must ensure somehow that every other developer reads and writes it the same way.

2. How do you alphabetize it?

3. Can you unambiguously determine when a user omitted entering a value, compared with intentionally leaving it blank?

4. How would you unambiguously query for the difference? Can a query screen user indicate NULL vs. blank using standard input form syntax?

5. In practice, I've never been prohibited from reading and writing data using default, unsurprising behavior using this rule. If I've needed to know the difference, I've used a boolean field (which is easier to map to unambiguous UI devices). In one case, I used a trigger to enforce True => null value, but never saw it invoked because the BR layer filtered out the condition effectively.

Solution 3

If the user provides an empty string, I always treat it as null from the database perspective. In addition, I will typically trim my string inputs to remove leading/trailing spaces and then check for empty. It's a small win in the database with varchar() types and it also reduces the cases for search since I only need to check for name is null instead of name is null or name = '' You could also go the other way, converting null to ''. Either way, choose a way and be consistent.

Solution 4

What you need to do is figure out what behavior you want. There is no one fixed algebra of how name strings are interpreted.

Think about the state machine here: you have fields which have several states: it slounds like you're thinking about a state of "unitialized", another of "purposefully empty" and a third with some set value. ANYTHING you do that makes that assignment and is consistent with the rest of your program will be find; it sounds like the easy mapping is

NULL → uninitialized
"" → purposefully unset
a name → initialized.

Solution 5

I try to keep things simple. In this case, I'd make the first-name column not-nullable and allow blanks. Otherwise, you'll have three cases to deal with anywhere you refer to this field:

1. Blank first name
2. Null first name
3. Non-blank first name

If you go with 'blank is null' or 'null is blank' then you're down to two cases. Two cases are better than three.

To further answer your question: the user entering data probably doesn't (and shouldn't) know anything about what a "null" is and how it compares to an "empty". This issue should be resolved cleanly and consistently in the system--not the UI.

View more solutions

Comments

[Otávio Décio]

Date of death is a typical use for NULL.

[Michael Haren]

Wow, I use NULLs a lot. Strings are really the only place where they don't fit nicely, in my opinion.

[Todd]

I use nulls a lot as well. I use them with dates to mean "hasn't happened" (date of death, or as a soft delete for a row, mentioned above). I use them where I don't expect user input as I find empty string (or string with spaces) too much trouble to factor out in a query.

[Alexander]

As I said, I'm sure you could find some use for it, but it doesn't make sense to have two sentinel values. Personally, for dates I use Unix timestamps since that's what I'd generally wind up converting them to anyway. My example is not instruction to avoid NULLs or DATE types.

[Michael Haren]

I guess I was just surprised by the "never, ever" part