Nando Dessena wrote (on the FB 2.0 Road Map thread):

> If I had a denullifying spray I'd spread it all over my
> databases. Having a way to represent missing or unknown
> values is one thing, three-state boolean algebra is a
> different matter.

There is a "denullifying spray" - its called triggers, lots
and lots of triggers. A PITA and rather annoying to have to
write or generate but it is the solution that I apply. But
even this does not negate NULL as an issue completely.

I have no particular problem with NULL or ternary logic. Once
it has been explained it seems a natural and fitting solution
to real situations - situations that even the self-professed
doyens of databases (C.J.Date et al) have been unable to
resolve in any convincing manner (well I am not convinced, and
that is whats important to me ;-).

What I object to is having it foisted on me everywhere,
instead of just those places where it is really must apply.

The idea of the equivalence operator or function (discussed
in the FB 2.0 Roadmap thread) is certainly a good idea and
worth having, but what I would really like is a variation of
default that avoids the need to write so many triggers to
denullify a database.

Perhaps the "missing value" capability that existed in early
interbase would be the solution (I've seen both Jim and Ann
speak of this), although I do not know the exact details of
how this worked.

I would be happy with a pre-insert/update trigger process
that enforced the default against null columns. ie. It would
actually store the specified value. Having it applied before
triggers execute simply means that you can write trigger code
that can assume the columns have values.

For my own purposes this new feature could be achieved without
any change in syntax - specifying a DEFAULT and NOT NULL for
a column should be sufficient to indicate my intention.
However it is possible to conceive of implementations that
have used this combination with other intentions (plus it is
probably not appropriate to implement non-standard behaviour
against standard SQL syntax), so I guess some non-standard
syntax would be required.


I am guessing that such a feature is not going to make it to
FB 2.0, but I was wondering if anyone had considered such an
idea for later versions. It really would make it much faster
to create and maintain a database - I am guessing that the
size of my SQL scripts would reduce upto 50% (sometimes more)
if I could remove all my "enforce the default" triggers.

--
Geoff Worboys
Telesis Computing