Ashish Karalkar wrote: > Hello All, > > Can anybody please point me to Advantages and Disadvantages of using view > > > With Regards > Ashish...
Well, IMHO views are part of the "business logic" and not of the data model. You can also think of them as an API to access the data from applications (clients). By defining some nice views, you allow writing a client with little knowledge about the actual database design. And clients written by different people access the data consistently. However, this is a two-edged sword. An API is usually designed to be generic enough. One day you may find you just need only part of the funtionality, and you that could do that part more efficently. That's expecially true if the API is used to hide the details away from you. Normal clients may be given access only to the views and not to the actual tables. That's pretty an good design principle, but again it cuts both ways. Think of a database with a "books" table and a "authors" table, with a nice view that joins them. One day you are writing a client application and want to fetch just the list of book ids. Yes, you can select one column from the view, but why execute the join when you don't need it? But if you're given access only to the view, you can't do much about it. Of course this is not specific to views, it's true for any abstraction layer in any context. .TM. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
