[iefbr14]

When the null concept was introduced to me in the seventies, the only thing I could say was that it would be causing a lot of unnecessary confusion in the future. If you have missing values in your datarecord then that datarecord belongs in an exception-queue. And now some 45 years later people are still discussing it like we did then..

[acuozzo]

> If you have missing values in your datarecord then that datarecord belongs in an exception-queue.

This depends on the context, no? I doubt there exists someone with a contact list on their phone which has every single field for every single contact populated.

There needs to be some way to codify that a field in a datarecord is unpopulated. Using the "zero value" for the type of the field (e.g., the empty string) is reasonable, but is this necessarily better than NULL? I reckon an argument can be made that this approach is just as likely to lead to bugs.

I'm not necessarily in favor of NULL, for what it's worth, but I can't think of an adequate replacement which doesn't reduce to "NULL in sheep's clothing".

[thfuran]

I did last week, before I added the first contact.

[DangitBobby]

Missing values are not always an exception. There's a reason modern languages almost universally include an Option type which may contain a Null and allow you to pass it around as a first class value. Good data representations allow you to express missing values.

[jfb]

Sometimes you want UNKNOWN, sometimes you want MISSING.

[iefbr14]

Just give the data item a status field, don't fix it by medling with a designated (non)value. And while you are at it you can add some valid-from and valid-to fields for the item. That's how you do it proper.