Comments on: The Joy of Null

By: Frederick Ross

Frederick Ross — Wed, 08 Apr 2009 21:28:25 +0000

Codd actually proposed separating null into a couple different types based on exactly this distinction. You’ll find it in some of his later writing on databases.

Of course, the major databases today don’t even implement the relational algebra in any meaningful way, so…

By: scott

scott — Wed, 08 Apr 2009 19:16:44 +0000

In reply to Kevin Wheat. This is definitely non-standard for most database systems.

By: Kevin Wheat

Kevin Wheat — Wed, 08 Apr 2009 19:08:45 +0000

Most of our java based web apps are dependent on iSeries database which is maintained in a case tool called synon. The resulting dds(data definition specs) can only support 3 datatypes
char,signed numeric and unsigned numeric. So a null in char(9) is nine blanks, a null in numeric is 0 etc.

By: KL

KL — Wed, 08 Apr 2009 16:51:59 +0000

I believe for Oracle you don’t really get a choice, since empty strings (“”) are coerced to null.

We had to create a “null-equivalent value” because our webapp would store empty strings for empty text fields, and then repopulate them with “(null)”.

By: scott

scott — Tue, 07 Apr 2009 23:54:15 +0000

In reply to vlad. A user entering a blank value isn't the same thing as the system inserting blank values. For example, if a user enters 2 spaces for a name, do you cut them off? This is far more dependent on your specific application model than anything that could be generalized. This article is more about developers writing code that actively inserting blank strings when it sees null or missing values.

By: vlad

vlad — Tue, 07 Apr 2009 23:27:02 +0000

Just one question: how do you detect that the user hasn’t filled in his middle name (null) or he has a blank middle name (”) ?
Generally speaking, when you have no flip switch to tell if a value is filled in or not, you never get nulls in the nullable columns, right?

By: scott

scott — Tue, 07 Apr 2009 22:50:18 +0000

In reply to CHB. Perhaps in MySQL it is problematic, MySQL's performance is among the weaker of the larger DBMS's. But inserting null-equivalent versus null values is more about the data model than performance. I've never heard anyard anyone claim they inserted an empty string on purpose because of performance reasons. Also, keep in mind if the field is VARCHAR, it could grow in size just as easily as null fields, granted that's more of a database-specific implementation issue to me.

By: CHB

CHB — Tue, 07 Apr 2009 22:45:54 +0000

The problem with allowing null fields in a tables (at least in MySQL) is that it leads to non-static-length tables; which can offer a large performance hit on i/o-intensive operations. Using null-like characters instead of allowing null fields and taking a performance hit is perfectly fine when A) your programmer(s) is expecting this, and/or B) when you have i/o intensive DB operations going on.

p.s. F’ your comment box. I had to rewrite this because I didn’t want to put an email/url in. The irony of not allowing nulls in this comment box section on this article is bittersweet.