Re: Views- Advantages and Disadvantages

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.

In response to

Browse pgsql-general by date

  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