On Tue, Dec 16, 2003 at 07:37:33PM -0800, Dann Corbit wrote:
> But as for the DEFAULT '' NOT NULL entries, CODD and Date eventually
> decided that NULL data was a big mistake.
<snip>
>
> I tend to agree that every column should have a default and not be
> allowed to become NULL. Just to keep end-user astonishment at a
> minimum.
Your argument does tend to support the idea that columns should not be
allowed to become NULL. That's what the NOT NULL attribute is for. But that
doesn't mean you should supply a default value. If the field is marked NOT
NULL and you forget to insert something, the statement should error out.
Silently filling with blanks is just waiting for a disaster to happen,
especially without RI.
Also, NULL does have some very useful situations, such as a BillID field for
a transaction that has not been billed yet. Using blanks means you would
have to invent a dummy bill '' to assign them to to satisfy foreign keys.
With NULL the problem does not exist.
Here's an idea, make all columns by default NOT NULL and add a new attribute
NULLABLE ;)
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> (... have gone from d-i being barely usable even by its developers
> anywhere, to being about 20% done. Sweet. And the last 80% usually takes
> 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce