Re: boolean datatype ... wtf?

On Oct 1, 7:39 am, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
> On Oct 1, 3:19 pm, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
>
>
>
> > On Oct 1, 2:58 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > On 1 okt, 15:54, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > > On 1 okt, 14:41, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
>
> > > > > On Sep 30, 1:04 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > > > > On 30 sep, 12:32, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
> > > > > > > Or we could create a plethora of tables like:
> > > > > > >  create table applications_with_garages (application_id references
> > > > > > > applications primary key);
> > > > > > >  create table applications_with_immobolisers (application_id
> > > > > > > references applications primary key);
> > > > > > > ... etc.
>
> > > > > > > That may be the right approach in a theoretical true RDBMS, but I'm
> > > > > > > pretty sure it would get me sacked as a lunatic in any SQL-based DBMS
> > > > > > > team!
>
> > > > > > If your SQL-based DBMS had proper physical data independence, then I
> > > > > > am quite convinced your claim would be false.
>
> > > > > But would this unary table approach to avoid a Boolean attribute
> > > > > really be considered good practice in a true RDBMS?  If I want to know
> > > > > "does the applicant's car have an immboliser", is the absence of a row
> > > > > in applications_with_immobilisers sufficient to answer it?  I thought
> > > > > that was a proposed solution to missing information ("it is unknown
> > > > > whether the applicant's car has an immobiliser"), now it seems to be
> > > > > acting as available information - i.e. the predicate "applicant 123's
> > > > > car does not have an immboliser".  Seems dubious to "record" a known
> > > > > fact by, er, not recording it.
>
> > > > Does this make a meaningful difference ?
>
> > > > I mean, you came up with the example of checkboxes on paper.  The
> > > > checkbox on paper can be "marked" if the corresponding label/property
> > > > is "true".  If the checkbox on paper is not marked, you interpret that
> > > > as "false", no ?  You wouldn't consider/interpret this as
> > > > "unanswered", or "unknown", or whatever, no ?
>
> > > > If the answer is two-way, then those two ways are isomorphic to "tuple
> > > > present"/"tuple absent", no ?  And "unknown"/"unanswered" simply
> > > > doesn't enter the picture, no ?
>
> > > > If you want to _explicitly_ take the option of "unknown"/"unanswered"
> > > > into account, then on the paper version, you would be _forced_ to
> > > > provide an _additional_ checkbox saying "I know the answer to the next
> > > > question", or "You can consider the next checkbox as having been
> > > > answered", no ?- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > > > - Tekst uit oorspronkelijk bericht weergeven -
>
> > > PS
>
> > > This is the same phenomenon as http forms containing a checkbox.
> > > Checked implies that the posted URL contains a <fieldname>=true
> > > portion, unchecked means that the posted URL does not contain
> > > <fieldname> at all.  Checkbox unanswered is, by itself,
> > > irrepresentible in HTML.
>
> > You have a strong point there!
>
> However, I can't help feeling it side-steps the real issue.  Assuming
> we DO want to distinguish between:
> - we KNOW the car has an immobiliser
> - we KNOW the car does not have an immobiliser
> - we DON'T KNOW whether the car has an immobiliser or not
>
> ... what is the correct way to model this?

Two unary relations? CarsWithImmobiliser and CarsWithoutImmobiliser? It sounds awkward, but think about it would you ever have any trouble when querying such a system (as compared to 3VL with NULL)? Received on Fri Oct 01 2010 - 18:37:20 CEST