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



True....

However, some of the developers using those other RDBMS's tend to make
all non PK columns NULLable.

It's not recommend, and I'd consider it just as bad if not worse than
refusing to use NULLs.

The recommendation for any DB, during the initial design make columns
NOT NULL WITH DEFAULT unless you've got a specific need to make them
NULL-able. NULL has to add some additional distinction. If you find
yourself using COALESCE or IFNULL to replace NULL values with blanks
or 0, then the column probably shouldn't have been NULLable in the
first place.

Example, consider a table with ADDRESS_LINE_1 and ADDRESS_LINE_2, I
can't think of a scenario where having a NULL value in ADDRESS_LINE_2
would provide me any benefit over simply having it blank (or empty if
it's a varchar).

On the other hand, HIRE_DATE, START_DATE, END_DATE...I can easily see
why END_DATE should be NULLable. A NULL END_DATE simply means the
employee still works there. The fun part is determining if HIRE_DATE
and START_DATE should be NULLable. I'd consider START_DATE a
probable, assuming you get hired, then a START_DATE is determined.
But the only reason to make HIRE_DATE nullable is if add candidates or
contractors to this table instead of just employee's. (Of course, in
that case the table shouldn't be named EMPLOYEES but PERSONNEL
perhaps. :)

Charles

On Wed, Aug 18, 2010 at 12:46 PM, Mark Murphy/STAR BASE Consulting
Inc. <mmurphy@xxxxxxxxxxxxxxx> wrote:
However, more and more we are going to be running up against other languages, like SQL, that handle NULL in a predictable defined manner.  When moving outside RPG, use of NULL is common.  So it is my contention that we should learn the proper use of NULL rather than just dismissing it because it is unfamiliar.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----


To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Charles Wilt <charles.wilt@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 08/18/2010 10:35AM
Subject: Re: Sql Question

John,

I agree, you shouldn't make a column NULL-able unless there's a
specific reason you need the NULL-able.

Charles


On Wed, Aug 18, 2010 at 10:19 AM, John Arnold (MFS)
<jarnold@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
The nature of null values is that they can only be found by a test for
null values - they will never show up in a not equal test - if you have
null values in your data you must test for values not equal and values
are null.

This is why my data base does not allow null values unless there is a
good reason for something to contain null values.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Tuesday, August 17, 2010 6:08 PM
To: Midrange Systems Technical Discussion
Subject: Sql Question

I have an SQL statement that compares data in for one table in two
different
libraries. The SQL just says report any record where the initials are
different but when I run it I get nothing.

I had one record where the initials for in one record was Null and in
the
other FUL but the SQL reported them as equal. That doesn't make much
sense.

Does SQL bypass the test if one side is null? Isn't null just a absence
of
data so they would not be equal? Have I found a bug (A big one?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.