Re: Date, Darwen, Pascal and the alternative to Nulls in the RM

"Paul Mansour" <paul_at_carlislegroup.com> wrote in message news:1142991689.461215.270180_at_j33g2000cwa.googlegroups.com...
> Assume one accepts, as I do, the argument against nulls put forward by
> Date et al. Would it be fair to say that at this point in time they
> really don't have a solution to missing information?

Its outside their theoretical scope.

> In the latest edition, just published, of the Third Manifesto (TTM)
> Date and Darwen do not include any recommendations on handling missing
> information other than pointing to a set of PowerPoint slides by
> Darwen, dated 2003. In fact, as the years go by, each of Date's
> books seem to have stronger and stronger proscriptions against nulls,
> and fewer and fewer ideas about how to handle missing information. The
> fact that at least 3 years after Darwen's slides on distributed keys
> they still did not include the concept in the new TTM book seems a
> pretty clear indication that they are really not that confident in the
> concept.

They lack any form of viable reality check in their theorising.

> Meanwhile, Pascal has 2005 paper "The Final Null in the Coffin",
> which seems a bit prematurely named (I haven't read it yet)
> considering the fact that it is advertised on his website as only a
> starting point or recommendation on how to avoid nulls, and that much
> research needs to be done.

The only way to avoid nulls is to avoid change management. That's it really. End of story. Change management will eventually breed the occurrence of nulls.

As change management is not incorporated into their theories, they are able to sustain a static rant endlessly. Nothing much has changed in the 30 years concerning their RM mantra.

Look at it as a 30 y/o cultivated blind eye.

> So, where does that leave an implementer who does not want to implement
> nulls? The leading theorists don't seem to have answers. Their
> proposed solutions may well cause more long run damage, just as nulls
> did, to the relational model. From nulls to special values, the
> proposed cures to missing information may well be worse than the
> disease. At this point in time, it seems that the prudent implementer
> would prohibit nulls, and essentially leave it up to users to design
> well, avoiding inapplicable information, and using application logic
> where necessary to handle missing information . Obviously this is not a
> good solution, but Date, Darwen and Pascal can't seem to offer
> anything better. Am I wrong here?

They lack integrity of experience in change management. They dream in a land of perfect design and no changes. Their world and your world are two separate universes.

My advice is to engineer provision within a database environment for the routine (automated) identification of specific data integrity exceptions, which will include the problems associated with nulls, but not restricted to this class of data integrity issues, and may include application related integrity exceptions [unless you write or purchace software which is always perfect].

It is important to design this data integrity exception management system in such a way that the users themselves perceive its benefits, and maintain its evolution through all change management scenarios.

There is no generic theory for this yet, neither for change management, neither for the consideration of the union of the data and the code. (The RM looks cycloptically at the data exclusively).

The above theorists are too busy elsewhere chasing the elusive non existent nulls, and writing commentaries upon commentaries upon commentaries.

What's new?

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
http://www.mountainman.com.au/software/Theory_of_Organizational_Intelligence.htm