Re: Why is database integrity so impopular ?

From: Roy Hann <specially_at_processed.almost.meat>
Date: Thu, 16 Oct 2008 09:23:38 -0500
Message-ID: <nKednVYqdK_302rVnZ2dnUVZ8v3inZ2d_at_pipex.net>


David BL wrote:

> On Oct 15, 10:08 pm, "Walter Mitty" <wami..._at_verizon.net> wrote:
>> "DBMS_Plumber" <paul_geoffrey_br..._at_yahoo.com> wrote in message
>
>> > 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."
>>
>> 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.
>
> I'd say impossible cases never arise by definition :)

I'd say I hear a lot of claims that things are impossible from people who didn't think about the problem hard enough to begin with.

I'd want some assurance that my database designer isn't using defaults (or nulls) to gloss over his own sloppiness.

Applications can supply default values if they're needed, but the DBMS should insist the applications conform to the business model implemented by the database schema (to the extent that is possible).

-- 
Roy
Received on Thu Oct 16 2008 - 16:23:38 CEST

Original text of this message