Re: Fwd: partial "on-delete set null" constraint

Alban Hertroys <haramrae(at)gmail(dot)com> wrote:

> Unfortunately, I do not own a copy so I can't verify. If anyone
> who does own a copy could confirm or even quote the relevant
> section, that would be great.

I have a copy of The RELATIONAL MODEL for DATABASE MANAGEMENT,
VERSION 2 (RM/V2), by E. F. Codd, Copyright 1990, on my desk, but I
wasn't entirely clear on what you were looking for a quote about.
In the preface he says that from 1968 to 1988 he published more
than 30 technical papers on the relational model, which he
collectively refers to in this book as RM/V1.

If you were looking for his views on NULL, I can tell you that in
1990 he preferred to refer to "marks" to indicate missing
information, and just the index entries on the topic would be too
big to quote here (taking nearly an entire page). The Missing
Information chapter is 27 pages long. The Response to Technical
Criticisms Regarding Missing Information is another 10 pages.
Also, these chapters refer to separate discussions of particular
issues related to missing values in other chapters.

He mentions that RM/V1 only had one type of mark for missing data
which was referred to in the earlier work as a *null* or *null
value*, so the term may have originated with him (I don't have
copies of all the relevant papers); but in RM/V2 he argues that the
difference between a value which is missing-but-applicable (just
currently unknown) is different enough from the case where a value
would be inapplicable (i.e., the value is unknowable) that there
should be separate marks for them, which he dubbed the A-mark and
I-mark, respectively.

I'm not aware of any product which has implementing the separate
types of marks for missing data, but I agree with his arguments
that while NULL is far superior to "magic values", the NULL concept
lacks enough semantic depth to avoid confusion. If I were
developing a database from scratch today I would try very hard to
implement his ideas regarding data marked as missing, but it's hard
to see how to retro-fit it into a stable product. :-(

If you have a question about a specific area of how missing values
should be handled according to RM/V2, please respond with a
question about it that is narrow enough to deal with in an email.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company