× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We realy are dealing with math here, and there are clear rules about operations. I will not argue if the rules are correct or if they make sense. Just as 2 + 2 = 4 wether you like it or not, the nulls have their rules. Nulls are an excelent way to deal with some bussiness rules, it is up to us, IT people to decide when to use nulls and when to use something else. SQL must implement the nulls in the way the matematicians defined they must behave. If you need some other behavior, don't use nulls.
____________________________________________________________________________________________
Joe Pluta wrote:

From: Raul A. Jager W.

In my opinion, nulls are better implemented in SQL than in RPG.  When I
compare a field in SQL I don't need to wory if it is null, neither in an
aritmetic operation.  Nulls compare always false, as they should and
give null when added to someting else.  In RPG I need check for null
(%nullind) before using the field.

Personally, I think NULL is just a hardcoded way of handling a standard
business problem.  You could just as easily use a field to check for
NULL, which is in effect what RPG does.

You say that NULL compare "always returns false, as they should".  What
happens when you compare two NULL fields?  I bet you can come up with
situations where you want this to compare as true, and some where you
want it to compare as false.

Or that adding a NULL always results in NULL.  There are plenty of
places where I might want the column to add as zero, not NULL.  So, no,
NULL does not always do what makes sense.  It just does what NULL does,
and that's whatever the NULL implementers thinks it should do.

In fact, what the NULL does is provide a hardcoded shortcut for what is
in effect a database design issue.  It's fine, but often overused.  And
there really need to be high-level capabilities to allow queries to
assign default values to NULLs without having to COALESCE them.  I'm not
against NULL, I'm just saying they're not perfect.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.