Re: practical view updates

"Mikito Harakiri" <mikharakiri_at_yahoo.com> skrev i en meddelelse news:bdf69bdf.0209300909.2cd2ae08_at_posting.google.com...
> "Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
news:<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]

[snippets again]
>
> ? I'm not saying that full equation solving system is something that
> DBMS desperately need right now. Besides the whole matter already
> settled queitly with adoption of INSTEAD OF triggers. My proposition
> is for the programmer to specify inverse view(s), rather than writing
> INSTEAD OF trigger procedural code. I admit, this is rather small
> economy, although, the added benefit would be the ability of the
> system to check correctness, namely that View*InverseView=1.

This approach seems interesting. I will think about it and revert to you if i have any questions.

> > > 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.
>
> By "default" value do you mean wrong value? This is the topic that
> never settled.

I believe that there is a distinction between default values and NULL values. This is the case in SQL as well. Thus, I would say that a default value is never a "wrong" value.
That the default value in the case in hand looks like a wrong value is another matter.
Your question becomes relevant when a language as D4 uses what is called "special values". In would myself like to know the difference between a special value and a NULL. So far as I can tell, this distinction is subtle and centered around the test for equality (giving true for special values and null for SQL, comparisons).

> >
> > I am not sure if one form is purer than the other. The second form looks
> > more consistent from my intuitive point of view.
>
> C.Date suggested eliminate updates from theoretical consideration and
> use equivalent delete-insert operations instead. Your transaction
> becomes:
>
> insert into contact (id, voice, fax) values (1, '123-4567','');
> delete from contact where ID = 1;
> insert into contact (id, voice, fax) values (1,
> '123-4567','555-5555');
> commit;
>
> which is equivalent to mine.

Yes - disregarding triggers and stuff like that. We have finished this discussion, perhaps.

Kind regards
Peter Koch Larsen Received on Tue Oct 01 2002 - 09:36:57 CEST