Re: View updating in practice?

Jens Lechtenbörger wrote:

> Dear reader,
>
> I wonder if anybody uses view updates in practice and if so what
> kind of updates on what kind of views.
>
> Personally, I believe that view updates are dangerous in most
> situations as users cannot understand what is going on. To give two
> simple examples: In case of deletions from projections, users delete
> tuples they do not know completely. In case of insertions into
> joins, users do not know whether they are actually inserting into
> both operand relations or whether there was a dangling tuple in any
> of the operand relations that gets "absorbed" by the newly inserted
> tuple. It is easy to see that users will not be able to undo their
> view updates (such that the old _database_ state is reached) using
> further view updates in the above situations. If a was a user of
> such a database I would be very irritated.
>
> I wrote a paper on this topic for ICDT'03. (Take a look at
> http://dbms.uni-muenster.de/publications/downloads/view-updates.pdf
> if you are interested in the details.) Unfortunately, the paper got
> rejected, but I'm not convinced by the reviewers' critique ;) Now,
> I would like to know what people do in practice. My questions are
> as follows:
>
> 1. Do you use view updates? What is the scenario?
> 2. If you do _not_ use view updates, did you at least think about
> using them? If so, what was the application scenario and why did
> you not implement it (e.g., no support by DBMS or too complicated
> for users)?
> 3. Does anybody use SQL:1999 INSTEAD triggers to implement view
> updates?
>
> I would be delighted if anybody out there was willing to share their
> experiences with me.
>
> Thanks in advance,
>
> Jens
>
> Follow-up set to: comp.databases.theory

1. Do you use view updates? What is the scenario?

    Yes. Whenever I want to build a data block (for example in Developer Suite) containing information from

    multiple tables.

2. N/A

3. Use INSTEAD of triggers on a regular basis to implement appropriate support of the views.

You do, in my opinion, make a number of invalid assumptions in your opening remarks. The biggest among them the fact that users have even the remotest clue of the design and structure of the underlying data. They don't know, they don't care, and likely they wouldn't understand it in without taking a class or two.

Software design is based on the concept of encapsulation. The ability to take complex functionality and present it in a clean, clear, and concise manner. If building a data entry form or report based on a view with instead of triggers serves that purpose ... then it is (assuming no problems with performance and scalability) the optimal solution.

And, while I understand you are involved in theoretical studies, and are likely deeply into academia, understand that end user's, and most developers, would know a tuple if it sat down with them for dinner.

Daniel Morgan Received on Fri Nov 08 2002 - 17:35:00 CET