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

[Ben Laurie]

Jonathan S. Shapiro wrote:
> 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.

I don't see why - if it makes sense to insert rows in a view that 
removes columns, that can only be so if the values for the hidden 
columns can be deduced from the visible ones plus context, surely?

I will readily agree that you can't do this in general, but in cases 
where you can't, then insert is simply not a valid operation.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff