×
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.
Walden H. Leverich wrote:
Use nulls, that's what they're for!
I'm not picking on you specifically, Walden, because many people have
contributed to this thread, but yours is the most on-point statement.
Anyway, not everyone agrees with your blanket assessment of nulls -
including folks like Chris Date and even Dr. Codd himself. A null in a
value (in this case, the termination date) could mean lots of things: it
could mean that the employee is still working for us (meaning there is
no termination date). But it could just as easily mean we don't know
what the termination date was, that the termination date we have is
invalid, or that the termination date hasn't been entered yet.
No, just about every database scientist whom I've read would insist on a
flag that indicates the status of the employee rather than relying on
the NULL value to give you any more information than the fact that you
don't have a termination date.
I won't belabor the point. I just want to make sure that the notion of
databases that is currently in vogue today often differs dramatically
from the folks who actually came up with the concept. That's not to say
that there is One True Database Design; Codd and Date actually disagreed
on nulls. But neither one agreed with the SQL approach.
So anyway, while the general assessment on this list of the use of nulls
is probably the most common one, that doesn't make it right. And it
certainly doesn't mean that RPG programmers who don't like nulls are
some sort of Luddites; indeed, it just means that they choose not to use
a specific technique - one that has arguably been misused or at least
overused by an entire generation of SQL programmers.
Joe
midrange.com
