Re: A question of principle

Hi Folks,

Let's see...
>
> > 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

Sticky to nulls. That's my point. Some people has already argued about the group functions, so I won't do it again... :)

> > ought to be. I find the blanks to be misleading and a misuse of >
> 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.

Good move !

> 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.

Do not agree with this. If you had a primary key it should never contain a blank value as part of it (in the case blank means null, i mean). What you're doing now is much more close to the real situation you have. Correct move, once again !

> 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.

Well, they're quick. In your case the drawback comes from the need to update hundreds of code lines, i see ! :)

There's not a better way then using the Database as it was designed to be used...

Nulls forever !

Regards,

Carlos Eduardo Souza Lopes
http://www.universo.com
lcel_at_universo.com Received on Sun Oct 27 1996 - 00:00:00 CEST