Re: On view updating

Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<2rg6cuF19au64U1_at_uni-berlin.de>...

> > In that case views are variables. Views and base relvars are
> > interchangeable and indistinguishable. An user can't know if he is
> > working with a table or a view.
> >
>
> Oh, yes. A user can know that even trivially.
> SELECT OBJECT_TYPE FROM USER_OBJECTS WHERE OBJECT_NAME='XXX'
I am not talking about specific SQL DBMSs.

> A proper relational database would give you away the fact that it is a
> view by simply typing it correctly
>
> typeof('XXX') => RelationType
> typeof('YYY') => REF RelationType

Wrong, in a proper relational database the type of a view is a relation type.

> An alias is typed as reference to a relation type.

You are talking about a non relational DBMS specific implementation detail.

> In order to prove your point you'd have to come up with a formal
> semantics for a SQL or Tutorial D database in which a '''formal'''
> mechanism for dealing with the state update can treat views and tables
> the same way.

I don't need that. I only need to check that the behavior of a variable is the same as the behavior of a view, and evidently it is the same. You can store and retrieve values from both. We are discussing the evident.

> You don't have that, Date doesn't have that, McGoveran doesn't have
> that. Their attempt to shoehorn view updates into the model suffer all
> the problems that we've talked about, and buys us precious little.

What we don't have is a way to resolve ALL the possible view variable assignments, but this is a completely different issue.

What you say is like to say that a car is not a vehicle because it can not work under the sea.

A view is a variable although we don't know how to resolve all possible assignments.

> * value types and reference types are distinct

Reference (pointer) types don't exist in relational databases.

> (l-values are distinct from r-values)

Or course!

This is a confusion prone bad terminology. l-values are variables and r-values are values (sometimes placed in variables).

http://faculty.juniata.edu/rhodes/lt/datatypes.htm

I will not use that terminology.

>
> In ML you have
> val x= ref 1
>
> or
> val y = 1
>
> x can be updated (it refers to a store that is initialized with integer
> 1) where y cannot be.

x is a variable and y is a value. It is rather simple.

> Therefore you have in imperative languages two categories
> * stores
> * expressions

There are variables and values.

In conventional imperative programming languages there are only expressions that return values, but in relational databases, there are also expressions that return variables. It seems that you are confusing expressions and values.

• A value expression returns a value:

2 + 2 = 4;

or

var a: Integer;
a := 2;
Write(2 + a); // 2 + a = 4

4 is a value and therefore it is immutable.

• A variable expression returns a variable:

select * from Customers = Customers

"Customers" is a relation variable and it is updateable.

Of course we could drop that feature and to have only expressions that return values. But most users would not be very happy with that.

> When you say CREATE TABLE you create a store, you define the type of the
> values stored in that place.

Agreed, you create a variable.

> When you say CREATE VIEW you create an expression and you give it a
> name. The fact that the expression can be *at a limit*
> (select * from table)
> does not make it less of an expression. You do not have a useful
> semantics that can map *any* expression to a store.

So what?

We have useful rules that can map many assignments on the derived variables to assignments on the base variables, and even whether we don't know all the translations we will obtain variables anyway.

We would have variables with which some or all the assignments would fail. The same as with tables.

With tables some of the assignments will fail because they violate some integrity constraints. With views some assignments will fail for the same reason and other will fail because the DBMS does not know how to resolve them. And perhaps other will fail because the DBMS knows several ways to translate the assignment but it can not decide which to apply.

In case we can't know any of the translations we could return a value instead of a variable, but this is a choice for the implementors.

> Therefore updatability of views cannot be viewed as a general mechanism
> in the model but rather as a synctactic shorthand that deals with
> special cases by translating them to real updates of real tables.

Non sequitur. Of course views are not a syntactic shorthand.

I would like to know what the other comp.databases.theory folks think about all this.  

Regards Received on Fri Sep 24 2004 - 13:03:34 CEST