[cap-talk] capabilities for databases and database-like systems
ben at algroup.co.uk
Tue Apr 19 07:40:02 EDT 2005
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
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.
"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
More information about the cap-talk