VIEWS compared to Nodes as Windows into data

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.

I have concluded, perhaps incorrectly, that the number of "windows into the data" (VIEWS) for Pat would be considerably larger than, say, the number of 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 reports (those that use table XYZ and those that don't, for example).

If viewing the data in a data tree through a particular node, where you are really navigating and not joining sets, there is no additional overhead from 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: The 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.]

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 that make this less of an issue than I am suggesting? Thanks. --dawn Received on Tue Apr 27 2004 - 18:02:09 CEST