Re: foreign key constraint versus referential integrity constraint

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 28 Oct 2009 21:41:41 -0300
Message-ID: <4ae8e4c5$0$26502$9a566e8b_at_news.aliant.net>


paul c wrote:

> Mr. Scott wrote:
> 

>> ...
>> Tables house data; views just present it. That is in a nutshell the
>> difference between tables and views. What is presented by a view
>> implies what is in the operands of the view's definition. As a
>> consequence, in order to be fully updatable and therefore
>> interchangable, each and every set of inserts, updates and deletes
>> applied to a view must map one-to-one to a set of inserts, updates and
>> deletes applied to those operands. Views that are joins or unions or
>> restrictions or projections in general aren't fully updatable. There
>> are exceptions, of course. A view defined on a pair of tables that
>> participate in mutual foreign keys is fully updatable because each and
>> every set of inserts, updates and deletes applied to the view maps
>> one-to-one to a set of inserts, updates and deletes applied to the
>> tables.
>> ...
> 
> Doesn't this amount to saying that tables are stored and views are not? 
>  (whereas I don't see why a view couldn't be stored because of some 
> practical reason or other.)

Ignore Mr. Scott. He doesn't know what he is talking about. Base relations and views equally represent data and neither houses anything, because housing implies something physical. A view can be stored or not stored. Regardless, a view is derived from base relations. Base relations, themselves, are derived from physical storage structures and might not be stored anywhere as is either.

It's easy enough to construct various schema with identical predicates where what is base in each is derived in all the others. The database designer generally chooses the base relations as a matter of his own convenience. Received on Thu Oct 29 2009 - 01:41:41 CET

Original text of this message