davidm@uunet.UU.NET (David S. Masterson) (08/24/90)
In article <1990Aug21.182201.10707@oracle.com> mfriedma@oracle.com (Michael Friedman) writes: Don't bother messing with views. This seems to be a general statement within the community. Why hasn't more emphasis been put on "views" as a mechanism for increasing the insulation between and application program and the database design? Isn't this what the model of views was to support? -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
gordon@mead.UUCP (Gordon Edwards) (08/24/90)
In article <CIMSHOP!DAVIDM.90Aug23103220@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> In article <1990Aug21.182201.10707@oracle.com> mfriedma@oracle.com |> (Michael Friedman) writes: |> |> Don't bother messing with views. |> |> This seems to be a general statement within the community. Why hasn't more |> emphasis been put on "views" as a mechanism for increasing the insulation |> between and application program and the database design? Isn't this what the |> model of views was to support? Views can be used to provide "external" models to users (including applications) and to enhance security. If there were not so many restrictions on their use then they would be very useful. I once worked on an Air Force proposal where we were planning to use views to "hide" data based on the level of the user. We were primarily treating views as read-only; update operations were transformed into base table updates. -- Gordon Edwards Mead Data Central, Dayton OH
chesky@portia.Stanford.EDU (Snehylata Gupta) (08/25/90)
In article <CIMSHOP!DAVIDM.90Aug23103220@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >In article <1990Aug21.182201.10707@oracle.com> mfriedma@oracle.com >(Michael Friedman) writes: > > Don't bother messing with views. > >This seems to be a general statement within the community. Why hasn't more >emphasis been put on "views" as a mechanism for increasing the insulation >between and application program and the database design? Isn't this what the >model of views was to support? It has been rather unfortunate. There are times when views can be very valuable tools. Sanjay
mfriedma@oracle.com (Michael Friedman) (08/26/90)
In article <CIMSHOP!DAVIDM.90Aug23103220@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >In article <1990Aug21.182201.10707@oracle.com> mfriedma@oracle.com >(Michael Friedman) writes: > Don't bother messing with views. >This seems to be a general statement within the community. Why hasn't more >emphasis been put on "views" as a mechanism for increasing the insulation >between and application program and the database design? Isn't this what the >model of views was to support? Hey, this isn't fair. I was responding to a particular problem. The person who posted was making an inappropriate use of views to solve a problem in an extremely awkward manner. I would never tell someone to avoid views in general. -- The passing of Marxism-Leninism first from China and then from the Soviet Union will mean its death as a living ideology ... . For while there may be some isolated true believers left in places like Managua, Pyongyang, or Cambridge, MA ... - Francis Fukuyama
davidm@uunet.UU.NET (David S. Masterson) (08/28/90)
In article <1990Aug25.213536.17280@oracle.com> mfriedma@oracle.com (Michael Friedman) writes: In article <CIMSHOP!DAVIDM.90Aug23103220@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >In article <1990Aug21.182201.10707@oracle.com> mfriedma@oracle.com >(Michael Friedman) writes: >> Don't bother messing with views. >> >This seems to be a general statement within the community. Why hasn't more >emphasis been put on "views" as a mechanism for increasing the insulation >between and application program and the database design? Isn't this what >the model of views was to support? Hey, this isn't fair. I was responding to a particular problem. The person who posted was making an inappropriate use of views to solve a problem in an extremely awkward manner. I would never tell someone to avoid views in general. Ooops, sorry. I didn't mean that to seem like I was picking on you. It just seemed like a good, general question to ask. Also, "the community" should not be read as "the vendors, alone". I've been a little disappointed (to say the least) with the capabilities of views that I've seen. For instance, can any vendors of applications built on a relational database (or anyone else, for that matter) suggest a good method of user security? Views seemed to be the method of providing restrictions on tables so that users see only what they are supposed to see. However, a vendor of an application has no users (and, therefore, no views) until he sells the product, so how can he build his product without knowing what the views are and how many there will be? Must the application designer move his security into the application and, so, remove responsibilities from the user's DBA? -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
nigelc@cognos.UUCP (Nigel Campbell) (09/01/90)
In article <1990Aug25.213536.17280@oracle.com> mfriedma@oracle.UUCP (Michael Friedman) writes: >In article <CIMSHOP!DAVIDM.90Aug23103220@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>In article <1990Aug21.182201.10707@oracle.com> mfriedma@oracle.com >>(Michael Friedman) writes: > >> Don't bother messing with views. > >>This seems to be a general statement within the community. Why hasn't more >>emphasis been put on "views" as a mechanism for increasing the insulation >>between and application program and the database design? Isn't this what the >>model of views was to support? > >Hey, this isn't fair. I was responding to a particular problem. The >person who posted was making an inappropriate use of views to solve a >problem in an extremely awkward manner. I would never tell someone to >avoid views in general. I would assume that most people do not create trivial views and discover very quickly that many are not updateable . As I responded before there are database systems (Starbase,Interbase possibly Rdb/Vms3.1/4.0) which through triggers make complex views updateable . However read only views are still very useful especially if the end-user is given ad-hoc reporting as he deals in the higher level entities (i.e. the view) not the physical implementation of an entity exploded into various atomic entities . Views also help satisfy the need to enforce security by value . In fact many Starbase/Rdb/Dg-Sql systems we have built have used views extensively to great effect programs are simpler to write/maintain - reduction in project costs programming errors are reduced - ditto also program specs can be more high level thus allowing the designer to spend more time refining the design logically and physically I have helped sites with applications where they experienced bad performance problems where views consisted of views and thus they went back to accessing the underlying tables directly . Not being a database internals guru I am not sure of what hurdles optimisers have to cross when determining the best strategy for such situations , would anyone like to comment on this ? -- Nigel Campbell Voice: (613) 783-6828 P.O. Box 9707 Cognos Incorporated FAX: (613) 738-0002 3755 Riverside Dr. uucp: nigelc@cognos.uucp || uunet!mitel!sce!cognos!nigelc Ottawa, Ontario CANADA K1G 3Z4
aaron@grad2.cis.upenn.edu (Aaron Watters) (09/05/90)
In article <8753@cognos.UUCP> nigelc@cognos.UUCP (Nigel Campbell) writes: ... >As I responded before there >are database systems (Starbase,Interbase possibly Rdb/Vms3.1/4.0) which through >triggers make complex views updateable . Could someone give an example of how this works? In particular if view V is the difference between R and S an `insert' to V could mean either an `insert' to R or a `delete' to S. What if you wanted to provide both interpretations? What about other such examples? Interested, -=aaron
ark@eclipse.stanford.edu (Arthur Keller) (09/13/90)
In article <8753@cognos.UUCP> nigelc@cognos.UUCP (Nigel Campbell) writes: > >I would assume that most people do not create trivial views and discover >very quickly that many are not updateable . As I responded before there >are database systems (Starbase,Interbase possibly Rdb/Vms3.1/4.0) which through >triggers make complex views updateable . However read only views are still >very useful especially if the end-user is given ad-hoc reporting as he >deals in the higher level entities (i.e. the view) not the physical >implementation of an entity exploded into various atomic entities . >Views also help satisfy the need to enforce security by value . > >In fact many Starbase/Rdb/Dg-Sql systems we have built have used views >extensively to great effect > > programs are simpler to write/maintain - reduction in project costs > > programming errors are reduced - ditto also program specs can be more > high level thus allowing the designer > to spend more time refining the design > logically and physically > >I have helped sites with applications where they experienced bad performance >problems where views consisted of views and thus they went back to accessing >the underlying tables directly . Not being a database internals guru I am >not sure of what hurdles optimisers have to cross when determining the >best strategy for such situations , would anyone like to comment on this ? > > >-- >Nigel Campbell Voice: (613) 783-6828 P.O. Box 9707 >Cognos Incorporated FAX: (613) 738-0002 3755 Riverside Dr. >uucp: nigelc@cognos.uucp || uunet!mitel!sce!cognos!nigelc Ottawa, Ontario > CANADA K1G 3Z4 Five years ago, I wrote a dissertation on how to update relational databases through views (actually, a large class of select, project, and join views). If anyone is interested, I could email out a list of references. It may also be possible to send out a collection of reprints, if demand isn't too high. Arthur