Re: The Practical Benefits of the Relational Model

Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<ankfe5$ppm$1_at_sp15at20.hursley.ibm.com>...
> And while I'm here guys, does this information equivalent formulation of
> the XOR case display the same semantics?
>
> drop table a;
> create table a(a integer not null, t CHAR(1) NOT NULL CHECK (t IN ('A',
> 'B')), primary key(a, t));
> insert into a values (1, 'A'), (2, 'A'), (2, 'B'), (3, 'B'), (4, 'B');
> drop view v;
> create view v as (select distinct a from a ) except (select a from a
> group by a having count(*) > 1);
> select * from v;

It does, because of the projection on the left side.

> And then should this version, now allow inserts? (note the DEFAULT clause)
>
> drop table a;
> create table a(a integer not null, t CHAR(1) NOT NULL WITH DEFAULT 'B'
> CHECK (t IN ('A', 'B')), primary key(a, t));
> insert into a values (1, 'A'), (2, 'A'), (2, 'B'), (3, 'B'), (4, 'B');
> drop view v;
> create view v as (select distinct a from a ) except (select a from a
> group by a having count(*) > 1);
> select * from v;
>
> If so, then I suggest for symmetry, there should be a way of specifying
> such defaults in the original XOR formulation as well.

Yes, inserts into this equivalent formulation succeed. It is worth noting that we have used different operators to obtain different update semantics before. For example, we have a join and a lookup in the language. The semantics for retrieval are identical, but for update, the join updates both inputs, while the lookup only updates the left side. Perhaps this same logic could be applied to alter the update semantics for some operators? We also provide the capability to write user-defined relational operators, so really, a user could provide their own operator with whatever update semantics they wanted.

Regards,
Bryn Rhodes
Alphora Received on Mon Oct 07 2002 - 22:41:35 CEST