Re: VIEWS compared to Nodes as Windows into data

<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).

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.

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?

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. 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>
Received on Tue Apr 27 2004 - 18:54:12 CEST