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

From: Cimode <cimode_at_hotmail.com>
Date: 13 Sep 2006 14:06:37 -0700
Message-ID: <1158181597.064456.70460_at_i42g2000cwa.googlegroups.com>


A simple alternative solution WITHOUT using the god damn NULLS... Flight entity is just equivalent to an assumed and recurring plane departure being associated to a specific departure airport. 1:N cardinality

_DT: departure_time
_AT: arrival_time
_ADT: actual departure time
_AAT: actual arrival time
_DA: departure_airport
_AA: arrival_airport
_ADA: actual departure_airport
_AAA: actual arrival_airport
_LN: last name
_FN: first name
_DOB: date of birth

Note: I use ONLY concatenated PRIMARY key (no surrogate, never liked them)

passenger:

            passenger_LN, passenger_FN, passenger_DOB plane_model:

            plane_model (PK), plane_capacity plane:

            planeid, plane_model
book:

            flight_DT, flight_DA, flight_AT, flight_AA, passengerlname,
passengerfname,                 passenger_birthdate
plane_flight:
            planeid, flight_DT, flight_DA, flight_AT, flight_AA

flight:
            flight_DT, flight_DA, flight_AT, flight_AA

plane_departure:
            flight_DT, flight_DA, flight_AT, flight_AA, flight_ADT,
flight_ADA
plane_departure_check:

            flight_DT, flight_DA, flight_AT, flight_AA, flight_ADT, flight_ADA, passenger_LN, passenger_FN, passenger_DOB plane_arrival:

            flight_DT, flight_DA, flight_AT, flight_AA, flight_AAT, flight_AAA

>From the above logical structure you can pretty much get anything you
want including:

> How late/early are the planes on current schedules
> If the planes could land at their supposed destination (you may associate a reason for it: BAD WEATHER, HIJACK). You know if the plane actually landed where it was supposed to land or not...You need to create and additional entity for that...
> What plane model should be scheduled to do a flight depending on book counts
> Which passengers did not leave where there were supposed to...

And many other information...
This is a purely pedagogical case (far from being complete) to demonstrate that it is perfectly possible to build some logical design in minutes (took me 20 of them) WITHOUT using NULLS...while sticking to the God Damn Real World (lazyness) excuse...

Regards all...

paul c wrote:
> JOG wrote:
> > Paul wrote:
> >> "JOG" <jog_at_cs.nott.ac.uk> wrote:
> >>...
> > The illogic of using nulls has been covered to death in the literature.
> > Surely you ought have read it given your job?
> > ...
>
> Right. If I may go further, if a single 'table' is seen as desireable
> for some reason, AFAIAC, actual departure time can be safely deemed to
> be equal to estimated departure time until the biz rules dictate that a
> plane has departed. I say 'biz rules' because the purpose of the system
> should dictate interpretation, not the viewpoint of an objective
> observer. I don't think this violates any RM principle.
>
> Some misconceived queries might use actual departure time to determine
> that a flight has departed (note the word 'flight' as opposed to
> 'airplane', this is a common abstraction in the airline biz', one of the
> few that makes sense, along with 'flight segment'), but the writers of
> those queries should think twice, assuming that the purposes of the
> schema have been explained to them. After all is said and done, a
> schema is an arbitrary abstraction, the fact that this is so is what
> allows us to make systems that are models of other systems.
>
> p
Received on Wed Sep 13 2006 - 23:06:37 CEST

Original text of this message