Re: Love or hate, or? domains with cardinality two

Op dinsdag 10 november 2015 20:14:57 UTC+1 schreef Tegiri Nenashi:
> On Thursday, November 5, 2015 at 3:08:19 AM UTC-8, Nicola wrote:
> > ... : are there good arguments
> > against (or in favor of) 0-ary predicates in database design? In a
> > nested relational database design I'd tend to prefer factoring out
> > 0-ary predicates into a separate 1NF schema. If you ask me why, well, I
> > posted exactly because I'm trying to find compelling arguments :)
>
> In every single database schema I have seen the design with boolean datatype was inferior to "normal" domain:
> - isManager in your example is clearly less informative than employees hierarchy
> - The design with isCreditWorthy boolean attribute literally begs for credit score

Curiously, way before I heard of the existence of the relational model, I often tossed around "codes are poor, entities are rich". Codes, and especially the Y/N kind, will tell you only Y/N. Entities can tell you so much more. Also, entities, and the SQL tables that implement them, are fairly easily extensible using standard data[base] management facilities. Extending Y/N with a "reason" or some such, which then only applies to the 'Y' cases, does not fit that description (well, if relational fidelity and null avoidance is worth anything).

> https://vadimtropashko.wordpress.com/2010/09/16/on-boolean-datatype-in-sql-and-beyond/
>
> It is up to proponents of Boolean datatype to exhibit schema where their schema design is superior.

I am not a fan of boolean attributes in relations.

http://shark.armchair.mb.ca/~erwin/booleandomains_0106.html

>
>
> > ... In a relation with a boolean attribute you are
> > effectively using a trick to encode both positive and negative
> > information (true and false propositions), while typically in a
> > relation schema you just represent only one kind of information. This
> > leads to situations in which you must guarantee some coherence (at
> > least one of (x,true) or (x,false) must be present in a valid
> > instance), as I have noticed in a previous post.
>
> Is it really that different from constraints & normal forms? If you impose FD id->isManager then you guarantee no contradiction. If you demand PK(id), then you add more consistency.
>
> > ... (*) It occurred to me that in Fagin's "A Normal Form for Relational
> > Databases That Is Based on Domains and Keys" he considers the
> > "combinatorial consequences of bounded domain sizes". It was something
> > about some logical equivalences not holding when domains of nonprime
> > attributes are "too small". But I don't recall all the details. Maybe,
> > rereading that paper will give me some insight.
>
> I noticed nothing special there: in conclusion to that paper the author stipulates that domain cardinality is greater or equal to 2.
Received on Mon Nov 16 2015 - 21:25:13 CET