Re: foreign key constraint versus referential integrity constraint

From: Mr. Scott <do_not_reply_at_noone.com>
Date: Wed, 28 Oct 2009 21:40:20 -0400
Message-ID: <Xu2dnaBFyaYYb3XXnZ2dnUVZ_hKdnZ2d_at_giganews.com>


"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news: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.

Ignore Mr. Badour. He doesn't know what he is talking about. Table definitions are constraints. View definitions are queries. The difference is clear to anyone who has a clue. (Obviously, Mr. Badour doesn't.) Constraints specify what can be true, not what is supposed to be true. Queries manipulate what is supposed to be true. Base relations (what are housed in tables) are not derived from physical storage structures: they are instead a logical expression of what is supposed to be true. How they are physically represented is irrelevant. What is presented by a view is the result of querying that logical expression of what is supposed to be true.

>
> 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 - 02:40:20 CET

Original text of this message