Re: NULLs

From: Sampo Syreeni <decoy_at_iki.fi>
Date: Tue, 8 Jan 2008 22:20:08 +0200
Message-ID: <Pine.SOL.4.62.0801082206210.18331_at_kruuna.helsinki.fi>


On 2008-01-08, Hugo Kornelis wrote:

> But of course, all these real world applications and all these text
> books still have to find some way to deal with missing information, so
> they often introduce magic values (like -1 in a numeric domain that
> should only allow positive numbers, 1900-01-01 or 9999-12-31 in a date
> domain, 'N/A' in a string domain, etc). This then turns out to be a
> far worse kludge than just using NULL for what it is intended to be
> used for!

Yes, and actually I think this brings up a further reason why nulls are often abused. There are many applications like open date ranges which invite the database designer to utilize an existing data type -- in this case a date -- which doesn't quite fit the job. After that you'd often want to extend the datatype to include special values like "valid until further notice". In typical DBMSes adding to the basic datatypes like that is not easy, so the one special value that can be added easily, null, gets overloaded. That is obviously bad, because unlike values proper, null invokes 3VL semantics which now have to be circumvented over and over in code, in order to mimic simple 2VL ones.

I think one means of relegating nulls to their proper place is to make it easier to avoid them where missing information is actually not the problem. That's then one reason why I think databases ought to have stronger support for custom, abstract datatypes/domains, in an easy to use form.

-- 
Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Tue Jan 08 2008 - 21:20:08 CET

Original text of this message