Re: sql views for denomalizing

From: Eric Junkermann <eric_at_deptj.demon.co.uk>
Date: Wed, 3 Aug 2005 23:08:50 +0100
Message-ID: <mXBUWZVyBU8CFw3u_at_deptj.demon.co.uk>


In message <1122996168.609599.96180_at_g44g2000cwa.googlegroups.com>, dawn <dawnwolthuis_at_gmail.com> writes
<snip/>
>Beauty is in the eye of the beholder. Think of a web page with a list
>of students in a class. Click on a student and you see all of their
>classes with the attributes of each class. Click on the class you came
>from and you are back to that first list. There is no need for an
>intermediate web page to cross references these two. They can store
>all of their references without having helper tables to do so. From a
>logical modeling perspective, this is much more elegant, don't you
>think?
<snip/>

I gave up on an earlier thread because my brain refused on that occasion to cope with answering things point by point, but that paragraph is a perfect illustration of what I mean.

The user interface described is clear and simple, I like it.

But then you start talking about storage, which has nothing whatever to do with interface design, and neither has anything to do with logical modelling.

The beautiful user interface does not own the data, even if it is the only current use of it.

As soon as you reflect your current presentation of the data in the logical and physical data design (especially if they are effectively the same), you have put a considerable barrier in the way of using the same data in some other way. Your logical model will be difficult to extend, and your physical design will have a high probability of performing badly for the new uses, or even for the same use as relative volumes of different data items change.

Where has all the elegance gone?

The logical data model should be about the data and only about the data. The physical design should be about finding an acceptable performance level for the logical operations that are currently performed.

There is no problem in having a structure clash between the logical model and the presentation of the data in a user interface, that is what programming is about.

The programmer's view of data is a short-sighted one, they should not be allowed to control the data model.

Eric

-- 
Eric Junkermann
Received on Thu Aug 04 2005 - 00:08:50 CEST

Original text of this message