Re: foreign key constraint versus referential integrity constraint

Mr. Scott wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message
> news:386975f9-472c-4184-8661-5c3d1e2f7621_at_r24g2000prf.googlegroups.com...

>> On Oct 24, 10:53 am, Keith H Duggar <dug..._at_alum.mit.edu> 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.)

Forgot to mention that I don't see that a "a constraint defined on a join" would necessarily be "of the form (p /\ q) -> r". I had thought that many people think it could be any truth-valued expression such as "(p /\ q) = r".

This leads me to think that most, if not all, view definitions can be interpreted as constraints. It is interesting to me to then ask what makes a view different from a base. Is it enough to say that a view always has one constraint (of possibly several) that is an equality and a view may be 'updated' without reference to the view?

A more opaque way but perhaps less useful way of saying this is that a relation's definition in the first place amounts to nothing more than a constraint. Received on Wed Oct 28 2009 - 19:41:48 CET