What are NULLs for?

Missing information? Then surely there should just be no tuple?

To indicate that there can be no value? Why not a seperate table with
a boolean value in the non-key column?

Steve B.

"stevedtrm" <stevedtrm (AT) hotmail (DOT) com> wrote

Go to google groups. Select the newsgroup comp.databases.theory

Do a search on NULLS. You will find a multitude of discussions about NULLS.
almost everything that this discussion might produce has been said in at
least one of those discussions.

Short answer: yes, it is to indicate that there is no value.

David Cressey wrote:
C'mon everybody!

NULL! - huh - yeah -
What is it good for?
Absolutely nothing!
Uh-huh

NULL! - huh - yeah -
What is it good for?
Absolutely nothing!
Say it again y'all

NULL! - huh - Good God
What is it good for?
Absolutely nothing!
Listen to me

You know the song...

Bob Badour wrote:

[snip]

(based, of course, on the Edwin Starr schema.)

On 26 Dec, 17:47, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote:
OK.

A brief perusal of those discussions gives me no reason to think NULLS
are necessary.

Furthermore, they reflect some sort of internal Codd/Date debate as to
how to handle NULLs. Something about 2nd and 3rd order logic (my
mathematics is too rusty to get anything more than an instinctive
grasp of this)

What were the two positions, hypersummarised?

If everyone is clear NULLS shouldnt be used, why the debate as to what
to do about them ?

stevedtrm wrote:

That's 2-valued logic versus 3-valued logic not 1st order logic versus
2nd order logic, which is a whole other discussion.


There are more than 2 positions. SQL introduced NULL as a very hackish
kludge. Codd pointed out that a single NULL marker did not suffice and
suggested 2 markers. Date pointed out that one can apply the same
argument to 2 markers leading to an infinite progression once one heads
down that path, which suggests the path was never a productive one to
head down in the first place.


Because SQL allows NULL and even promotes the idea that NULL solves some
problem instead of introducing many.

So everyone is agreed that NULLs shouldn't appear anywhere, and its
just a matter of time before NULLS become a legacy problem and a
relational language supercedes SQL?

Are the two solutions I suggested before the widely accepted as
resolutions to the two problems NULLs were introduced to eradicate?

"stevedtrm" <stevedtrm (AT) hotmail (DOT) com> wrote

It depends who answers the question. I am pretty sure that there are very
few relational theoreticians who will defend the use of nulls today.
Unfortunately there are very few relational theoreticians. On the other
hand the overwhelming majority of practitioners enthusiastically embrace the
use of nulls. There is a very large and growing number of practitioners.
Since your question is about popularity, you can see the answer is obvious
now.

I am a practitioner myself, and I feel pretty lonely discouraging the use of
nulls. There are a variety of reasons why they must continue to be used in
the short-term, mostly to do with the inadequacy of our programming tools.
Those won't change for two reasons: programmers won't ask for what they
don't know they're missing, and programmers seem not to want database tools
very much anyway.

For the last few years I've been trying a different way of discouraging my
colleagues from using nulls. I've noticed that almost all of the nullable
attributes introduced into our systems are there to permit multiple fact
types to be confused in one table. (There seems to be an intuitive desire
to minimize the number of tables in a database. I don't know whether that's
a psychological thing or whether it is something to do with reducing the
amount of code that needs to be written.) Anyway, I have been able to show
that decomposing these kinds of tables so that distinct fact types use
distinct tables often incidentally produced very striking performance
improvements too. I have been able to make the point out that these designs
allow you to exclude nulls, and I have started to encourage them to look for
that feature during design, as an indicator of future performance. By not
over-selling the idea, and by starting with demonstrable benefits, I have
won some sympathy. Once I have some sympathy I can make more complicated
arguments. The other benefits of eliminating nulls have emerged
automatically in time.

Outer joins continue to re-introduce nulls though. I'm not sure what to do
about them.

Roy

On Dec 26, 7:17 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:
Date's argument here seems to me iron-clad.

My one point of amplification would be to claim that the various
markers
are *application-specific.* And the role of the system in dealing with
application-specific issues is to provide the appropriate mechanisms
for application writers to use, and *not* to try to anticipate the
specifics
every application will need and provide them ahead of time.

Which is to say, I interpret all the NULL-related difficulty as yet
another argument for user-defined types.


Marshall

On Dec 27, 2:37 am, "Roy Hann" <specia... (AT) processed (DOT) almost.meat>
wrote:
I have observed this as well.

I've seen the same thing in OOP land. As a former regular of
comp.lang.java.programmer, I can attest that it was pretty common
to see an exchange where someone posed a problem, someone
else came up with a lovely solution in the form of a new class,
and the OP rejected the solution because it created a new
class.

I suppose the desire is to minimize the number of distinct
abstractions,
however any single-metric approach to code quality is going to suck.

Still, it can be kind of funny when you think of it. Hey, I'm using
SQL and I need to solve this problem. Why not try xxx? Oh no,
even though I'm using SQL I don't want to solve this problem
with a *table.* Ha ha.


Marshall