Re: View updating in practice?

Hallo Jens,

I think a problem in your paper is that it does not consider other features of SQL.
For example it would be feasable to disallow the trainer to delete members from the team view.
Instead he could be allowed to UPDATE the "member-of team" column (which would need to be provided in TEAM) and thus hire and fire as he pleases.

As indicated by others INSTEAD OF triggers are a way to enforce the semantics you wish (although in my knwledge thay are NOT part of the SQL standard (yet)).
E.g. the DELETE can be interpreted as an update to said underlying member-of-team column. And an INSERT could do the same. Coincidentally I recently published a (sample oriented) article on this topic. It's aimed at DB2, but applies to Oracle and MS SQL Server just the same:
http://www7b.boulder.ibm.com/dmdd/library/techarticle/0210rielau/0210rielau.html

The reasoning you use can equaly be applied to base tables. In specific it would suggest that triggers as well as cascading RI constraints would be harmful since the user might not be able to even find his row again (the before trigger might change, or even generate, the primary key). The RI constraint or after trigger may have impact throughout the database making it impossible to recover with the limited knowledge.
Does this mean that database side logic is bad?

Gruss nach Muenster
Serge

-- 
Serge Rielau
DB2 UDB SQL Compiler Development
IBM Software Lab, Toronto

Visit DB2 Developer Domain at
http://www7b.software.ibm.com/dmdd/