Re: Why is database integrity so impopular ?
Date: Wed, 15 Oct 2008 14:08:18 GMT
"DBMS_Plumber" <paul_geoffrey_brown_at_yahoo.com> wrote in message news:264bdc0d-d884-4bc3-88a3-2ecb5183b056_at_t39g2000prh.googlegroups.com... On Oct 14, 12:28 am, David BL <davi..._at_iinet.net.au> wrote:
> 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
Outstanding reply. I'd go even further. I'd say that in data management, impossible cases arise routinely. Planning your systems so that they do something reasonably intelligent when the impossible happens is just plain good engineering.
PS, causing an inrecoverable failure during the weekend batch update, when only a skeleton crew is on duty, is an example of unreasonable behavior. I can't tell you the number of production systems that behave this way when required data is missing.
PPS, the whole discussion of default values has ignored a valuable distinction, unless I missed it along the way. There are two points in time when a default value can be susbstituted for a NULL: at INSERT or UPDATE time, or at query time. If defaults are substituted at INSERT or UPDATE time, the fact that a default was used is lost, unless that fact is recorded somewhere else. You can't, in general, know whether the application provided a value that just happens to agree with the default, or whether the application provided a NULL, and the system plugged in the default.
Substituting a default value at query time is best illustrated by the COALESCE function. There are however, some DBMSes that provide for substituting a default at query time, which save application programmers and data analysts the trouble of coding it in. Received on Wed Oct 15 2008 - 16:08:18 CEST