Re: VIEWS compared to Nodes as Windows into data
Date: Fri, 30 Apr 2004 14:55:24 +0300
- Post for FREE via your newsreader at post.usenet.com ****
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> 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,
SQL VIEWS are the SQL DBMSs equivalent of derived relations. An user view of a relational database is the USER SCHEMA. An user schema could be made of many base and/or derived relations.
> I have concluded, perhaps incorrectly, that the number of "windows into
> data" (VIEWS) for Pat would be considerably larger than, say, the number
> filing cabinets that Pat might have had to use to get the same information
> in the past. This is so that the user can see the data from a variety of
> perspectives, is not limited to a single filing cabinet when viewing the
> data AND so that the VIEWS can help optimize performance for various
> (those that use table XYZ and those that don't, for example).
Are you saying that there is a problem with RDBMSs because of the need of an user schema for each perspective on data?
> If viewing the data in a data tree through a particular node, where you
> really navigating and not joining sets, there is no additional overhead
> any given view if you can see fields from XYZ through that view and don't
> use them. So, conceptually, the user asks questions of top-level nodes
> which would be roughly the same as the named filing cabinets, with the
> exception that through these windows into the data values, the user can
> choose to see values from anywhere to which one could navigate. [Note:
> user need not DO the navigation as the vocabularly for the node can be
> extended to include any data to which one could get from this node.]
What made you think the joins are actually performed when you define a view
Maybe the joins are not performed until you actually use those fields.
> IF I have this right, this seems to me to be a significant issue for
> relational databases -- how to get simplicity for the user without them
> having to care about which view to use to get the best performance and
> without making a large number of views in order to have those with and
> without many different tables in the join. Or are there database
> implementations that help this situation in some way or best practices
> make this less of an issue than I am suggesting? Thanks. --dawn
The relational model is just a language that allows one to talk about
the data in a database.
If you think there are problems with the relational databases, you may search for them in:
- the implementation
- the expressiveness and succinctness of the language
- Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=