Re: A question of principle

Bard wrote:
>
> I am a DBA. We have several developers working with our setup of Oracle
> Data Warehouses. The source of our data is a mainframe.
>
> The question of principle has to do with transferring mainframe practices
> to the Oracle warehouse. Primarily, the use of "blanks" or "spaces" in
> place of NULLs. I am, on principle, opposed to using blanks where nulls
> ought to be. I find the blanks to be misleading and a misuse of Oracle. I
> also believe it sets a poor precedence for future Oracle applications.
>
> I would appreciate any and all opinions. Am I being too uncompromising?
> (If it's of any use, we are using the star-join modelling technique as
> opposed to normalization.) Does anyone else out there allow only blanks
> to be entered into a field? If so, how is it working? Anyone out there
> replace blanks with nulls where there were already blanks? If so, did you
> have trouble teaching the users the concept of null values?

We have a similar situation in our large Pro*COBOL application. By nature, the COBOL prefers to have things padded with blanks, and that's how we implemented it initially. We are now looking at moving to using true NULLs instead of blanks.

One problem we're fighting with is that many of our composite primary keys were based on some columns being blanks, and that's, or course, a no-no in Oracle. We had to change to a UNIQUE index to enforceness the uniqueness portion of the key, and then we set a NOT NULL constraint on columns that never did, or should never, contain NULLS, like the first column in the key for example. Kind of kludgy, but necessary until we make changes to the way the programs handle NULLs and blanks internally.

Another drawback of using NULLs is that to really use them properly, I think you have to have NULL indicator variables in your host programs wherever a column can be NULL. This can be a pain because you have these indicator variables strewn throughout your programs.

If you find out any other good information, I'd be interestes in hearing it. Hope my information helps.

Thanks,
Brian

-- 
Brian M. Biggs				mailto:bbiggs_at_cincom.com
Cincom Systems, Inc.			voice: (513) 677-7661
http://www.cincom.com/