Re: Why is database integrity so impopular ?

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 14 Oct 2008 18:45:49 -0700 (PDT)
Message-ID: <1e339364-eeac-47fc-bb4a-015b20e441fb_at_x16g2000prn.googlegroups.com>


On Oct 15, 1:09 am, DBMS_Plumber <paul_geoffrey_br..._at_yahoo.com> wrote:
> On Oct 14, 12:28 am, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Oct 14, 12:17 am, DBMS_Plumber <paul_geoffrey_br..._at_yahoo.com>
> > wrote:
>
> > > If you mandate that a column cannot contain a NULL, setting a DEFAULT
> > > means that when a programmer legitimately doesn't have a value for the
> > > column they aren't obliged to put in there the first thing that
> > > springs to mind.
>
> > How can a programmer legitimately not have a value for the column?
> > Doesn’t that imply that the schema is inadequate (for supporting
> > partial information)?
>
> In engineering, shit happens. Design with failure in mind.
>
> I'm not going to argue for two weeks with 'Max' in accounting about
> about whether he has a legitimate reason to not know the close date of
> some transaction. Waste. Of. Time. I'm not going to expect
> perfection; especially not out of programmers.
>
> It seems prudent management practice as well as sound engineering to
> say simply that "If you don't know - that's OK - just go with the
> default."

No doubt many applications need to support partial information. I wonder whether there’s a risk with using default values as far as being at odds with the principle that unusual cases or exceptions should be explicit, not implicit. What’s prudent seems to depend on the dangers of getting it wrong. Received on Wed Oct 15 2008 - 03:45:49 CEST

Original text of this message