Re: VIEWS compared to Nodes as Windows into data

"Laconic2" <laconic2_at_comcast.net> wrote in message news:-eWdnfWwUNhhEhPdRVn-sA_at_comcast.com...
> <orthogonal>
>
> VIEWS are an enormously useful feature of relational databases (I know, I
> know, there's no such thing, but this is the orthogonal zone).

thanks for taking this ride with me in this zone!

> VIEWS provide an addional layer of independence between the user of the
data
> and the actual storage of it, beyond the layer implicit in tables as such.

Most assuredly, as does the metadata in PICK -- there it is done one field at a time (by way of the vocabulary -- all dictionaries are "logical dictionaries").

> As an example, let's go back to something you asked a couple of weeks
ago.
> It was the question of how to convert a one-to-many relationship into a
> many-to-many relationship. Let's say that the designer, thinking ahead,
> decided to be ready for this situation in some particular case. E.g.
we're
> going to matrix management next year, so the boss relationship is going
to
> become complex.
>
> If the designer had created a view that joined the two tables, and the
DBA
> granted access to the view, but not to the underlying tables, to the user
> community, then all that would be needed would be to remove the foreign
key
> from one of the tables, replace it with a new table containing two foreign
> keys, write some procedure to keep the new table current, and rewrite
the
> view to use the new table instead of the foreign key that was embedded in
> the old table. Is this clear?

Yes and what just struck me with what you said is that with an RDBMS it is actually possible for a user to write a report using the query language against something that is NOT just a logical view of the data -- YIKES!

> As far as VIEWs and performance goes, this is where existing DBMS
products
> have had an extremely checkered career. In the really dumb shops I've
seen,
> they had a rule about "no views, because VIEWS slow everything down".
> Many of the soi disant Relational DBMS products did have a poor
relationship
> between the optimizer and the view feature during the 1980s. But the best
> products have gotten beyond that, for about ten years now.

> Encouraging people to use views, without absolutely requiring it, can be
> acheived by giving views an extra level of support.

Why would you EVER let an end-user run a query against a base table definition?! If you change the table def, then I guess you could write a view that "looks like" the previous version of the table, but you would have to rename it, right? So, if there are any reports written against base tables and the base table def changes, then all such reports have to change? I'm going off on a tangential, but related topic 'cause this just seems like one of the reasons why PICK does better for ease of maintenance even though the RDBMS was written to make it better for that. I'll think about that one.

> If a view runs slow, we'll assign a higher priority to speeding it up
than
> if a user query runs slow.
>
> This is all very practical stuff, and is therefore orthogonal to the true
> religion.

orthogonal to orthodoxy, eh? That'd be me. --dawn

> </orthogonal>
>
>
Received on Tue Apr 27 2004 - 19:23:49 CEST