Re: views of binary operations

From: David Cressey <dcressey_at_verizon.net>
Date: Sun, 16 Jul 2006 11:03:52 GMT
Message-ID: <s2pug.5004$T87.364_at_trndny05>


"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1153017368.456165.270950_at_m73g2000cwd.googlegroups.com...
> Consider named views of binary operations on relations.
>
> Given a relational operator "op" and relation variables A and B,
> and a declaration of:
>
> r = A op B
>
> the language evaluates the expression "A op B" and assigns the
> result to r.
>
> However, if we declare this as a view, we do not evaluate A op B
> at the time of the declaration, but instead (re)evaluate A op B each
> time we make reference to r in later expressions.
>
> r = view(A op B)
>
> Is it the case that we want exactly the above, or might we
> want a more fine-grained control? Might we ever want
>
> r = A op view(B)
>
> In other words, the value of A at the time of the declaration and
> value of B at the time of evaluations of r? In which case, we
> then have four possibilities:
>
> r = A op B
> r = view(A) op B
> r = A op view(B)
> r = view(A) op view(B)
>
> (Actual evaluation of the expression is deferred if either of
> the operands is a view.)
>
>
> In other words, when we have a view of a binary relation operation,
> are we necessarily creating a view of the entire expression, or are
> we making views of the operands?
>
> (I am asking in the theoretical sense, and not about SQL per se,
> although if current practice in SQL sheds light on the question,
> I am interested in that as well.)
>
>
> Marshall
>

The product I'm most familiar with, DEC Rdb/VMS did not provide an answer to this at the SQL level. The net effect of CREATE VIEW in Rdb was to make reference to named tables or views by name in the definition, rather than by value.
The substitution of view definition for named view was deferred to execution time.

The question of retrieval strategy, optimization, and reuse of a prior optimization, was the subject of some ingenious trickery, so as to cut down on the munber of repetitive optimizations on the same query, without reusing a strategy that has become obsolete.

Consider the following:

CREATE VIEW US_ADDRESSES AS SELECT * FROM ADDRESSES WHERE COUNTRY_CODE = 'US';

ALTER TABLE ADDRESSES ADD COLUMN EMAIL_ADDRESS CHAR(25); Now, the next reference to US_ADDRESSES is going to deliver the new column, if the expansion of the wildcard is deferred. If, however, the expansion of the wildcard is carried out at definition time, the addition of the new column won't be reflected in the view. Come to think of it, I forget which way Rdb worked in this regard.

It's an interesting question, if views are being used to obtain a higher level of logical data independence than is conveniently available without views.

I realize this does not address your question, Marshall. But it may add a new point to the discussion. Received on Sun Jul 16 2006 - 13:03:52 CEST

Original text of this message