Re: Joins with nulls

"Finarfin" <finarfin_at_sympatico.ca> wrote in message news:uGDD9.36286$hK2.1371992_at_news20.bellglobal.com...
> David Cressey wrote:
>
> <snip>
>
> > Nulls in databases result from outer joins.
>
> < snip >
>
> Here we come to the crux of the problem.
>
> Consider the example of a relvar for proper names.
>
> How do you create a relvar for proper names. (To clarify, my proper
> name is John Eggert). Do we create two base relvars?: First Name;
> Last Name, or a single relvar, say: Proper Name. If we go with option
> 1 ( two base relvars), all base relvars must consist of (at most) two
> columns. In his case: First Name Index and First Name, etc.. This is
> the option that eliminates nulls (and duplicates). (This can be
> proved by induction). This is obviously absurd, hence by reducto ad
> absurdum, the theorum (no nulls in a relation) is rejected. This
> isn't rocket science. Why is it such a matter of contention?

If first name and last name are always known, I see no need to put them in separate relations. The absurdity lies in your example and not in any problem of data management. For someone with a single name, like Meatloaf, make the last name an empty string. We know what the value of an empty string is: a string of zero characters. An empty string equals any other empty string and collates "less than" any non-empty string.

> Another way (less vigourous) of saying this is: Nulls in a database
> are inherent in the underlying data and ARE NOT a result of joins.

Since NULL is never inherent in any known data, I fail to see a point in your assertion.

> As such, any system that cannot tolerate nulls will eventually come
> crashing against the solid wall of reality.

Why is that? You have not given a single example of a problem caused by lack of support for NULL.

> JE
Received on Sat Nov 23 2002 - 22:11:07 CET