[cap-talk] capabilities for databases and database-like systems

[Jonathan S. Shapiro]

On Sat, 2005-04-09 at 10:46 -0700, John Carlson wrote:
> >> 2. In most DB systems, There are restrictions on the operations that can
> >> be performed using views. That is, views were added as an afterthought
> >> rather than as an essential model.
> >
> >
> > The restrictions on operations that can be performed on views are
> > essential to the function of views, not just some omission because
> > views are an "afterthought".  In particular views can be composed
> > of joins of other tables.  If one is then going to update a view, which
> > table or what from the tables gets updated?
> >
> You can put the keys to the underlying table in the view, and then
> the underlying tables will get updated.  At least according to one
> Oracle expert I talked to.  I've never tried it myself.

There is a consistency problem. If a view exposes rows selectively, the
only problem is running consistency filters while attempting the update,
and this can be solved.

Deletes can be handled correctly as long as row identity is preserved,
even if the row is partially exposed.

The difficulty is that a view can also expose *columns* selectively,
which raises the question: what should be inserted for columns that are
not present in the view? Also, if the view does not expose all of the
joins of the underlying data set, there is a related consistency
problem.

So: I think there *is* a conceptual difference between a dynamic filter
(the result of a select, but one that fully exposes the relevant join
structure and all columns in each member record) and a dynamic table (a
view that removes columns and/or omits some component of a join).


shap