Re: Implementation of boolean types.

-CELKO- wrote:
> You missed the class on scales and measurements.

and I just read a good treatment of that in a new book called SQL PROGRAMMING STYLE. I am pleased to say that I can recommend the book, even if not all of the ISO standards :-)

> SQL deliberately left
> out Booleans and deprecated bits. They are a sign of "punch card" and
> assembly language programming.
>
> >> I personally think that this should be design using a relationship with other tables such as Human <<
>
> No, you should use a CHECK() on a vlaue that is limited to a particular
> scale.

It is still a shame not to have a boolean type, you've gotta admit, right?

> Your sex code example has an ISO Standard which you would have found if
> you researched before you coded. 0= Unknown, 1= male, 2= female and 9=
> lawful person (corporations, organizations, etc.)

It was MUCH better when male was 0 and female was 1 -- at least each of these two genders were valued as an identity ;-) rather than one being SECOND -- ugh!

When ISO came up with this standard, what percentage of existing databases provided more than two possible values for gender? If someone is uncertain, show two signs from restrooms and ask which restroom they are most comfortable entering or flip a coin. Define the attribute as being a "best fit" for a value for gender among those available (such as M & F). Then if they indicate they are concerned about having to provide a gender value, flip a bit, I mean give another attribute such as hasGenderConcerns a value of "T" (or true).

> Get a copy of SQL PROGRAMMING STYLE for some details on how to create
> encoding schemes -- there is no single magic answer.

I see you have read the book too ;-) I'm only half way through, but I'll pass you an attaboy on it, Joe. So far, I have found it helpful, clear, readable, and it addresses practical questions people have.

I don't know how we are going to get past the underscores in attribute names vs camelCase names issue, however. I'd appreciate more consistency in naming throughout an application and camelCase is here to stay. Also, when you put your data catalog on a web site as hypertext with standard html styling, you don't lose visibiliy of any of the attribute name (the underscore). The fact that some dbms's have upper/lowercase issues in 2005 is not a reason to set the industry standards there. I'll expect that fixed in the next edition of the book, OK? :-)

Cheers! --dawn Received on Thu Jul 14 2005 - 04:01:18 CEST