Re: TOP N Query

From: Billy Verreynne <vslabs_at_onwe.co.za>
Date: Thu, 12 Dec 2002 08:37:42 +0200
Message-ID: <at9avl$77$1@ctb-nnrp2.saix.net>

Tim X wrote:

>> >The proper way would be to design the database and table to meet the
>> > end-user requirements.. :-)
>>

> Not sure I can agree here. I've seen too many databases which were
> designed with the end user requirements being considered to be the
> primary goal at the cost of propper modelling of the data and
> identification of correct entities and their relationships. The result
> is often a "de-normalized" database design.

I agree Tim. I was by no means advocating not to use Codd and design a "proper" database. However, when it comes to the physical implementation, there are numerous way to skin the cat. Without knowing how the database is going to be practically used, the wrong decisions can easily be made.

> While I don't think you should ignore end-user requirements, they
> should not have too much influence in modelling and design.

Agree. But there are also a physical design. Clustering. Partitioning. Etc. There are PL/SQL, JAVA, Pro*C. What to use where. Knowing _how_ the database is going to be used, is critical in designing the physical layer, deciding on the access layer, etc.

> It is also
> difficult to predict what the end user requirements will be.

Yep. But then predicting should not be in the equation at all. End user requirements must be detailed in the URS and Functional Specs of the system. And signed. They just love to move the goalposts and paint them in a different colour. ;-)

> However, I think it is a credit to the original
> designers this database has managed to still be productive and it has
> been possible to incorporate a web interface without too many
> difficulties .

Yes. A good solid design goes a very long way. Wish I could personally see one or two of them on the databases I'm looking after...

--
Billy

Received on Thu Dec 12 2002 - 00:37:42 CST