Re: practical view updates

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: Mon, 30 Sep 2002 12:31:57 +0200
Message-ID: <3d982821$0$52173$edfadb0f_at_dspool01.news.tele.dk>


"Mikito Harakiri" <mikharakiri_at_yahoo.com> skrev i en meddelelse news:bdf69bdf.0209291808.6348efe3_at_posting.google.com...
> jingleheimerschmitt_at_hotmail.com (John Jacob) wrote in message
news:<
72f08f6c.0209281332.3efe8b6d_at_posting.google.com>... [lots of snippets]

>
> In other words, you exclude domain operators from the view update
> analysis?
> Then, you miss many practical problems like updating the view
>
> select FirstName || ' ' || LastName from customer

How on earth could a view like that be updateable? An if it (due to restrictions on FirstName and/or LastName) was updateable, is this kind of deduction something we in your opinion should be able to expect from a standard DBMS?

> > create table Contact
> > {
> > ID : Integer,
> > Voice : String { default "" },
> > Fax : String { default "" },
> > key { ID }
> > };
> >
> > create view ContactPhone
> > Contact over { ID, Voice } rename { Voice Phone } add { "VOICE" Type
> > }
> > union
> > Contact over { ID, Fax } rename { Fax Phone } add { "FAX" Type };
> >
> > Not only is this view updatable, but I would argue that it has
> > precisely the desired affect your example implies is impossible to
> > determine. The insertion of the row row { 1 ID, "VOICE" Type,
> > "123-4567" Phone } satisfies the predicate for the left side of the
> > union, and so is inserted there. The update through the add is
> > successful because the value of the Type column is indeed "VOICE". The
> > update through the rename, obviously, succeeds, and the update through
> > the project succeeds as well (because of the default definitions). The
> > effect is then the insertion of the row row { 1 ID, "123-4567" Voice,
> > "" Fax } into the Contact table.
> ---^^^^^
>
> There are 2 problems.
>
> 1. NULL value in the Fax column. Mr. Date doesn't admit NULLs, so how
> application of his rules suddenly contain one?

Actually, there are no NULLs here, just default values.

>
> 2. It is not a single tuple insertion that must be translated, but the
> whole transaction.

Is it so? This puts a much larger burden on the system.
>
> insert into phoneview (id, type, number) values (1,'VOICE',
> '123-4567');
> insert into phoneview (id, type, number) values (1,'FAX', '555-5555');
> commit;
>
> is equivalent to
>
> insert into contact (id, voice, fax) values (1, '123-4567',
> '555-5555');
> commit;
What is wrong with the following translation?

insert into contact (id, voice, fax) values (1, '123-4567',''); modify contact set fax = '555-5555' where ID = 1; commit;

I am not sure if one form is purer than the other. The second form looks more consistent from my intuitive point of view.

Kind regards
Peter Koch Larsen Received on Mon Sep 30 2002 - 12:31:57 CEST

Original text of this message