From: | Marco Colombo <pgsql(at)esiway(dot)net> |
---|---|
To: | Ashish Karalkar <ashish(dot)karalkar(at)info-spectrum(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Views- Advantages and Disadvantages |
Date: | 2007-05-10 16:12:43 |
Message-ID: | 4643447B.7000103@esiway.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | David Wall | 2007-05-10 16:39:34 | Re: Replication for PG 8 recommendations |
Previous Message | Christian Rolle | 2007-05-10 13:19:22 | schema of system tables |