Re: View updating in practice?
Date: Sun, 10 Nov 2002 00:32:51 -0500
Message-ID: <1fmz9.158$bu4.79166488_at_radon.golden.net>
"Jens Lechtenbörger" <lechtej_at_uni-muenster.de> wrote in message
news:m2of9087s0.fsf_at_pcwi1068.uni-muenster.de...
> 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:
Jens,
I am reading your paper. With all due respect, it starts with a straw man argument that assumes the database designer is as clueless as the casual user.
If you were trying for a "proof by contradiction" that adding irrelevant attributes to an employee relation is a bad design, I think that simpler proofs would do.
Skipping ahead to the conclusion, I tend to agree with the direction of your conclusion; however, I found nothing but generalities there.
Sometimes I will want a delete on a projection view to delete more than the user sees. Sometimes, I would consider that an design error. What design principle can I use to allow the former and to alert me to the latter? Give me something concrete that I can take home. Something like http://www.pgro.uk7.net/principle1.htm
> 1. Do you use view updates? What is the scenario?
I do not use view updates because I use SQL. In general, SQL does not support view updates, and where it attempts to support view updates, it does not support them correctly. Without logical identity, it will never be able to support them correctly.
> 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)?
I would enjoy using an RDBMS that properly supports view updates. I can think of innumerable scenarios for using updateable views covering a range of issues from distribution to security to configuration management.
> 3. Does anybody use SQL:1999 INSTEAD triggers to implement view
> updates?
I don't know about others. Given an option between a view and a trigger, I would choose the view.
> 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
Received on Sun Nov 10 2002 - 06:32:51 CET
