Re: VIEWS compared to Nodes as Windows into data

From: Christopher Browne <>
Date: 29 Apr 2004 17:52:40 GMT
Message-ID: <c6rfd8$ff7nb$>

Centuries ago, Nostradamus foresaw when "Dawn M. Wolthuis" <> would write:
> "Dawn M. Wolthuis" <> wrote in message
> news:c6m06j$r1h$
>> Given a database application implemented in an RDBMS with 632 tables where
>> we want to give Pat an online data catalog from which to shop for data
>> values by way of metadata, we would likely provide a set of SQL VIEWS,
>> correct?
>> From what I have seen, if there is data in a supporting table XYZ that is
>> only sometimes needed when reporting about a particular entity (such as
>> Customers), then one might have two VIEWS of that data -- one with and one
>> without XYZ joined in.
> <snip>
> Is this an accurate perspective on SQL VIEWS? Are there "extra" VIEWS, more
> portals into the data, or whatever, created simply for performance reasons?
> Is there a DBMS that provides a better top level "data catalog" that doesn't
> include performance issues mixed with what data values you can "shop for"
> (query)?

VIEWS are created for all sorts of reasons, typically:

  • To provide convenient perspectives on data;
  • To structure the data better from a security perspective.

They aren't created for "performance" reasons; if anything, they are likely to cut performance slightly. Their point is either to provide better abstraction or to to hide details.

(reverse (concatenate 'string "moc.enworbbc" "_at_" "enworbbc"))
Rules  of the  Evil Overlord  #194. "I  will make  several ludicrously
erroneous maps to  secret passages in my fortress  and hire travellers
to entrust them to aged hermits." <>
Received on Thu Apr 29 2004 - 19:52:40 CEST

Original text of this message