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

Paul wrote:

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

>>>Otherwise you have to take account of the fact that these aircraft
>>>took off in 9999 or else in 0001 or whatever.

>>Or whatever. One describes the actual departure time of a flight in a 
>>relation describing actual departures and not in a relation describing 
>>aircraft.

I disagree. The attribute you described was for an actual completed flight and not for a schedule at all. A scheduled flight would have a scheduled departure and a scheduled arrival defining a scheduled before, a scheduled during and a scheduled after. As anyone who has taken a few flights--especially anyone who has flown on the Romanian national airline--can attest, the scheduled before, scheduled during and scheduled after need have no particular relationship to the actual completed before, actual completed during or actual completed after, which any reasonably intelligent person would define in a sentence describing an actual completed flight using an actual departure and an actual arrival.

> That way, one can run reports on, say, Scheduled_Departure_Time
> against Actual_Departure_Time to check on punctuality (a stat that
> some airlines publish in their advertising - I know that Ryanair
> does).

Since no NULL attribute is required to form the query in question, I fail to see any point in what you wrote here.

> What value would *_you_* put in for *_Actual_Departure_Time_* in such
> a table?

I would not use any Actual_Departure_Time attribute to describe a scheduled flight. I would use such an attribute to describe a flight in progress or a completed flight.

>>>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.

>>How is null easier than not inserting anything into an actual departures 
>>relation?

I agree the relation variable describing completed flights exists before any particular flight departs. I further agree the relation variable describing flights in progress exists before any particular flight takes off. However, neither relation variable need have a tuple describing any scheduled flight before it takes off.

• the Scheduled
  > time is there, the pilot's name might be there, the aircraft type
  > might be there,
  

Why would I have the scheduled time in relations describing the actual flight? It's already available in the schedule. The pilot's name or the aircraft type, of course, might differ from the schedule.

  but the actual time is a field which should be in the
> table, with a null value until such time as the Ops staff are happy
> that it has taken off - unless you are suggesting a separate table?

Of course, I am suggesting a separate relation. I am not an idiot, and only an idiot would suggest otherwise. Received on Tue Sep 12 2006 - 21:42:24 CEST