Re: WWW/Internet 2009: 2nd CFP until 21 September x

Walter Mitty wrote:
> ....
> The way I think of it is that every table with nulls in it is a materialized
> outer join. If you can decompose the table into multiple tables each of
> which has no nulls, what you discover is that a null in the combined table
> corresponds to an absent row in one of the decomposed tables.
>
> Let me shift gears back into practical mode for a minute. In any database
> I've ever worked with, the majority of columns are not a primary key, or a
> foreign key or a part of a primary or foreign key, or ever appear in a where
> of having clause. Nulls in those columns are of almost no consequence at
> all in the overall behavior of queries. Shunning nulls in those cases is
> being overly picky.
>
> Nulls in "important" columns almost always cause more trouble than
> decomposing tables would cause, but nulls in inumportant columns help keep
> things simple.
...

An implicit suggestion here is that there is a way to determine which apps are 'simple' in some sense, eg., not capable of contradictions, other than by avoiding nulls. I don't mind people advocating nulls as long as they don't pretend they have a theory, logic and algebra that makes their use contradiction-free. If they want their cake and eat it too, they could get to work figuring out SQL might prevent the definitions and statements that cause apps to be 'non-simple' in some useful sense. Received on Sat Aug 15 2009 - 20:22:11 CEST