Re: foreign key constraint versus referential integrity constraint

From: Mr. Scott <>
Date: Mon, 26 Oct 2009 03:06:29 -0400
Message-ID: <>

"Marshall" <> wrote in message
> On Oct 24, 10:53 am, Keith H Duggar <> wrote:
>> Anyhow, the question here is not one of our imagination but rather
>> simply this: if it makes sense for the RM to support constraints
>> on relational /values/ (taken on by variables) why does it not
>> make sense to support constraints on relational /expressions/?
>> That is a question of general principle not specific design.
> This question, it seems to me, is clear and to the point.
> And I would answer it by saying that we shouldn't really
> even make the distinction! (At least not formally.)

I think we should make the distinction, and formally.

(p /\ q) -> r is not the same as (p -> r) /\ (q -> r) but (p \/ q) -> r is the same as (p -> r) \/ (q -> r)

A view consisting of a natural join, for example, represents a set of conjunctions. Each row of the join represents a conjunction of propositions, one for each operand. A constraint defined on a join would be of the form (p /\ q) -> r. That is definitely not the same as constraints defined on one or more tables, which would take the form (p \/ q) -> r.

> There are quite a lot of constraint taxonomies out there,
> and I haven't ever really been able to derive any particular
> value of any of them. Most generally, ever constraint
> is a constraint on the entire database; if the constraint
> mentions only a single variable, then we might say
> it is a "table constraint" or "relvar constraint" or some
> such, but that's only a degenerate case of a database
> constraint. So let us say there is only one type of
> constraint, the database constraint, and be done with it.
> Now that I've said that, let me take it back a bit.
> Transition constraints don't seem to be quite like
> anything else. Transition constraints are therefore
> annoying. :-)
> It's Sunday and I'm hot, so I'm posting with
> reckless abandon. Read my sentences at your
> own risk.
> Marshall
Received on Mon Oct 26 2009 - 08:06:29 CET

Original text of this message