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

Paul wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote:
>
>
> > > > That's nice. I simply don't allow null in any database I design.
> > > Why not?
> > you're kidding right?
>
>
> No.
>
> > > Scheduled_Departure_Time = 'DD:MM:YYYY 10:15'
> > > Actual_Departure_Time = <null> untill we know different, then we put
> > > in a value.
>
>
> > So an aircraft might not take off and yet it has a departure time
> > attribute? That makes absolutely no sense at all.
>
>
> I see that you are from Nottigham university - I would have thought
> that a reasonable grasp of the English language was necessary to
> either take or give courses there.
>
> What part of "Scheduled" did you not understand?

Sorry, I am not interested in peurile flaming games so I will simply ignore this. I am only interested in helping people with theory so that the field may progress.

>
> I can *_schedule_* a flight for Dublin airport for 6 months time - the
> damn airport might have been dirty bombed by Osama and his pals in the
> meantime, meaning that the aircraft will never take off from there.
>
> I don't know how familiar you are with aviation, but *_actual_*
> departure time is important - pilots fill out VR's (Voyage Reports)
> which are legally binding documents which have to have the actual
> departure time (apart from pay issues for staff).

Whether the attribute is "Scheduled" or "Actual" departure time is completely irrelevant. In fact the whole example is irrelevant - it matters not whether you are talking about aeroplane takeoffs, employee records or monkey fish.

So I repeat, If an attribute does not exist for a certain statement, why /on earth/ are you trying to record it? The formal proposition you are encoding does not fit the predicate you are attempting to kludge it into. This is basic theoretical stuff.

>
> Now, if the field "Actual_Departure_Time" is not null, then it has to
> be something - yes?

No. You do not understand what the tool you are using is doing. The field should be in a separate relation, obviously. Then if no value for the field exists, no row is input.

>
> That "something" is normally some arbitrary value - i.e. 01/01/1970 or
> whatever - the point is any application programmer has to take that
> system defined arbitrary value into account when writing code against
> the system.
>
> *_WHEN_* the value used is <null>, then the programmer doesn't need
> any special knowledge of the system - i.e. "By the way, the date for
> planes which haven't taken off yet is xxx/yyy/zzzz" - just a simple,
> "Oh, that's null until the VR is filed".
>
>
> What could be simpler or more logical?

The illogic of using nulls has been covered to death in the literature. Surely you ought have read it given your job?

Either way, I gave you a rudimentary breakdown of the simplicity of the matter here:
http://groups.google.com/group/comp.databases.theory/msg/62dedf999812fd70

and Roy Hann expanded here:
http://groups.google.com/group/comp.databases.theory/msg/44edaf876e369802

I refer you back to them.

Many take pride in their professions. I can only encourage you to do the same, and get up to speed on the theory.

>
>
> Paul...
>
>
> --
>
> plinehan __at__ yahoo __dot__ __com__
>
> XP Pro, SP 2,
>
> Oracle, 9.2.0.1.0 (Enterprise Ed.)
> Interbase 6.0.1.0;
>
> When asking database related questions, please give other posters
> some clues, like operating system, version of db being used and DDL.
> The exact text and/or number of error messages is useful (!= "it didn't work!").
> Thanks.
>
> Furthermore, as a courtesy to those who spend
> time analysing and attempting to help, please
> do not top post.
Received on Wed Sep 13 2006 - 02:05:34 CEST