Re: 3 value logic. Why is SQL so special?

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 11 Sep 2006 23:16:53 GMT
Message-ID: <F7mNg.530756$iF6.413774@pd7tw2no>

Paul wrote:
>
> Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
>
>

>>>  FWIW, I try to create subtypes
>>> where there are no nulls.

>

>> That's nice. I simply don't allow null in any database I design.

>
>
> Why not?
>
> (Personal work experience). Aircraft. Flight Schedules.
>
> Dep time,
> Arr time,
>
> &c.
> ...

The point gets made here over and over that personal work experience is most often the worst basis for talking about designs but some people continue to tout it. Before Codd came along, the airlines had THE state-of-the-art networks after that they "missed the boat" if I may put it that way. I'd say any airline example is at least doubly poor because of their tpf/acp heritage which placed almost total emphasis on physical design to the detriment of the logical, not to mention the adhoc and mostly thoughtless IATA regulations/so-called standards. My personal experience helping one airline go bankrupt argued more for suppressing the bulk of their traditional techniques wherever possible.   (Of course I wasn't completely responsible for that bankruptcy, eg., that airline had 6 people in IT for every plane!)

p

>
> Scheduled_Departure_Time = 'DD:MM:YYYY 10:15'
> Actual_Departure_Time = <null> untill we know different, then we put
> in a value.
>
>
> Otherwise you have to take account of the fact that these aircraft
> took off in 9999 or else in 0001 or whatever.
>
>
> Null is easier. The aircraft hasn't taken off yet, we don't know when
> it will take off, or even if it will take off.
>
>
> Paul...
>
>
>
Received on Mon Sep 11 2006 - 18:16:53 CDT