Re: The BOOLEAN data type

Anith,

  Either you misunderstood me, or I misunderstood Bob. I thought he was saying boolean should _not_ be used for a column representing gender as the value of "is male". I thought it was fine to use a boolean for that. So I'm not sure why you suggest I define a type, since Bob is the one who doesn't like the existing type, not me.

  Bob used as an argument against a boolean table column that implication didn't make sense for "is male". Whether it does or not, it sounds like you are agreeing with me and pointing out that SQL just doesn't have the capability to specify which operators are allowed with which types.

Steve

Anith Sen wrote:

>Steve,
>
>
>
>>>Just because an operation exists for a type doesn't mean it has to make
>>>
>>>
>sense for every entity represented by that type. <<
>
>Well, define your own type, then.
>
>I think you misinterpreted Bob's point. The Boolean type has only two values
>(true, false) and a set of operators that apply to them. If your business
>model requires values other than true or false, then you need to define
>another domain with relevant values & associated operations those values
>support and use this domain in your logical model. If gender in your
>business model means, 'male' and 'female' (note, these are character
>strings), then create a domain along the lines of :
>
>TYPE gender POSSREP ( CHAR );
> OPERATOR (<>, = );
>
>You can define your own operators based on your requirements as well like:
>
>OPERATOR xyz (g1 CHAR, g2 CHAR) RETURNS CHAR
> RETURN (IF g1 = g2 THEN g1 ELSE '') ;
>END OPERATOR;
>
>Types allow the user to meaningfully compare the values in a logical model
>against other values in the same domain. Also note that the operators, being
>type-defined, will disallow other meaningless comparisons like
>concatenation, >=, < etc. Thus the DBMS will know exactly which expressions
>are legal and the type of the result for each such legal expression. It can
>preserve domain integrity efficiently thereby, knowing which assignments and
>comparisons are legal as well.
>
>Simply trying to create a comparable logic in a language (case in point,
>SQL) which does not even support the basic concept of domains does not hold
>water in this case.
>
>--
>- Anith
>(Please respond only to newsgroups)
>
>
>
>
>
>
Received on Sat Apr 12 2003 - 22:56:14 CEST