Re: VIEWS compared to Nodes as Windows into data
Date: Tue, 27 Apr 2004 12:23:49 -0500
"Laconic2" <laconic2_at_comcast.net> wrote in message
> 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!
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
> 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.
> going to matrix management next year, so the boss relationship is going
> become complex.
> If the designer had created a view that joined the two tables, and the
> 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
> 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
> 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
> have had an extremely checkered career. In the really dumb shops I've
> they had a rule about "no views, because VIEWS slow everything down".
> Many of the soi disant Relational DBMS products did have a poor
> 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
> if a user query runs slow.
> This is all very practical stuff, and is therefore orthogonal to the true
orthogonal to orthodoxy, eh? That'd be me. --dawn
Received on Tue Apr 27 2004 - 19:23:49 CEST