From: PC

To: Fabian Pascal

 

I enjoyed your exchange with GM about "Denormalization, redundancy and multi-value DBMS" (whatever multi-value DBMS is, I don't know).

 

It seemed to me that the only specific case mentioned by GM (mentioned but I would say not illustrated) in his or her argument is in this excerpt:

 

"... Where it then saves on joins is that if I want to retrieve information--for example, in a sales application--on a customer order I can get the order number, customer number and the line item data (e.g. product codes, quantities, prices charged, etc) in one read. I don't have to store the product names and a whole lot of other product-related information against each line item".

 

GM is clearly talking about physical matters. I find it telling that GM doesn't consider what should be obvious to anybody who has done much physical optimization which in my experience usually revolves around one or two attitudes: 1) examine the biz requirements and get rid of functionality that doesn't address them (of which there is has been a lot in the systems I've been asked to look at, or 2) shift internal work from one function to another.

 

At the risk of taking a simplistic view, it seemed obvious to me that the case mentioned is entirely amenable to a "stored view". Note that I am talking "physical" here, not "logical" - I think you would agree that the logical part of the DBMS should not be aware that the view is stored.  Anyway, this attitude says that if retrieval cost is deemed more important, then the cost of maintaining the stored view should be borne by the updating function(s).

 

I look forward to your "forthcoming commercial database foundations series". How will it be available?

 

 

From: Fabian Pascal

To: PC

 

These people all suffer from logical-physical confusion and they lack knowledge of data fundamentals.

"Stored view" is a contradiction in terms. What you mean is that it is possible to store joins and make the “base tables” views (this is the idea behind clustered tables). However, that requires ability to update multitable views (which SQL products do not permit) and, like with every physical configuration, it is better for applications that access the join and worse for those that access the views, the opposite of what happens when the base tables are stored. There are tradeoffs.

 

But the real solution in the relational spirit is to get rid of physical rows altogether. That's what the new technology I allude to does, but unfortunately I can't yet talk about it.

 

It will all be electronic -- paying via something like PayPal and then downloading it from the site. But initially it may have to be manual, by check and emailing of the paper.

 

Posted 04/04/03

 

 

 

[ABOUT] [QUOTES] [LINKS]